LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 09-01-2011, 11:38 AM   #1
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Rep: Reputation: Disabled
Rkhunter warnings (hopefully not related to the kernel.org breach)


As many here will already know, kernel.org (one of the websites where Debian users can obtain iso images for installing Debian systems) has been breached, and some software available there has apparently been infected with the Phalanx trojan. See
I run a Debian Lenny system. In early July 2011 I
  • upgraded to v. 5.10.0-19lenny5 of perl, perl-base. perl-modules, libperl5.10 (source 128.31.0.36 steffani.debian.org)
  • upgraded to v. 7.18.2-8lenny5 of curl, libcurl3, libcurl3-gnutils (source 128.101.240.212 debian-mirror.mirror.umn.edu)
Since then rkhunter has given warnings for perl and curl:
Code:
Warning: The file properties have changed:
*** File: /usr/bin/curl

...
*** File: /usr/bin/perl
(Both stored hash and inode have changed.)

I have assumed that this is an innocuous glitch due to rkhunter not knowing about the Debian changes, but the recently revealed breach at kernel.org (which is among other things a website where users can obtain upgrades for debs) has impelled me to inquire about this discrepancy. rkhunter does not find evidence of the Phalanx trojan on my system.

I always upgrade promptly and note which repo I use for each upgrade. Fortunately, I have not used the kernel.org repository during the period 1 July 2011 to present, but if the curl and perl packages in Debian isos offered at kernel.org turn out to have been tampered with, the above information may be useful. In this case I will provide the hashes.

Last edited by Peufelon; 09-02-2011 at 04:41 PM.
 
Old 09-01-2011, 01:45 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,675
Blog Entries: 54

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Quote:
Originally Posted by Peufelon View Post
As many here will already know, kernel.org (..) has been breached
Yes, it was posted today already.


Quote:
Originally Posted by Peufelon View Post
and some software available there has apparently been infected with the Phalanx trojan.
The name is Phalanx2 and not Phalanx. Phalanx2 is a rootkit and not a trojan. Rootkits usually do not "infect" stuff (and if any binaries in the kit are contaminated already then it'll be with RST and not much else).


Quote:
Originally Posted by Peufelon View Post
I always upgrade promptly and note which repo I use for each upgrade.
That may be so but if these changes occurred early July 2011 then asking about things two months later means you're not responding promptly to changes. Kind of begs the question why you would run verification in the first place?..


Quote:
Originally Posted by Peufelon View Post
I have assumed that this is an innocuous glitch due to rkhunter not knowing about the Debian changes,
Rootkit Hunter is as distro-agnostic as possible so you mean local changes. And don't assume but make certain. See Rootkit Hunter documentation, the FAQ: 4.4) After performing some updates, all, or some, binaries in the file properties checks are marked with a 'Warning'.


Quote:
Originally Posted by Peufelon View Post
(..)if the curl and perl packages in Debian isos offered at kernel.org turn out to have been tampered with, the above information may be useful.
No, if the ISOs changed then the ISOs hash changed and if it was cryptographically signed the signature shouldn't match either. In the absence of anything on that level to compare with, extracting and comparing package contents with upstream should provide evidence.
 
Old 09-02-2011, 03:28 PM   #3
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
Quote:
The name is Phalanx2 and not Phalanx. Phalanx2 is a rootkit and not a trojan. Rootkits usually do not "infect" stuff (and if any binaries in the kit are contaminated already then it'll be with RST and not much else).
You are the expert, and I was posting in haste. Thanks for the correction. I agree that these distinctions are important.

Quote:
See Rootkit Hunter documentation, the FAQ
Sorry that in my rush yesterday, I didn't state this clearly, but that's why I suspected that the warnings were probably innocuous. I run tripwire and rkhunter immediately after each update so it was clear why rkhunter thought something had changed: something had. I ran rkhunter --update and afterwards still got the warning, so I tentatively concluded that rkhunter simply had no way of knowing about the Debian changes to curl and perl.

Here's what I would have said yesterday if I'd had time: the security updates to Debian Lenny (oldstable) which caused the Rkhunter warnings are
http://lists.debian.org/debian-secur.../msg00143.html
http://lists.debian.org/debian-secur.../msg00138.html

Quote:
if these changes occurred early July 2011 then asking about things two months later means you're not responding promptly to changes. Kind of begs the question why you would run verification in the first place?
Cause you're the goto guy for RkHunter but you and I seem to suffer from chronic miscommunication, and frankly you can be kinda scary when you become frustrated by my requests for advice/assistance.

Anyway, I think you are saying that the warnings are probably innocuous, but that you can't be sure without getting the source code from the Debian repos. Or the binaries installed on my system?

There's this but I don't even know what to look for:
Code:
strings /usr/bin/curl | wc
   1165 ...
objdump -m i386 -b binary -D /usr/bin/curl | wc
  37760 ...
strings /usr/bin/perl | wc
   6390 ....
objdump -m i386 -b binary -D /usr/bin/perl | wc
 382408 ...

Last edited by Peufelon; 09-02-2011 at 04:00 PM.
 
Old 09-02-2011, 04:18 PM   #4
John VV
Guru
 
Registered: Aug 2005
Posts: 13,459

Rep: Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800Reputation: 1800
rkhunter normally gives false positives on brand new 5 min. old installs
normally it is the /bin and /usr/bin links or a script that is used to launch the program .
 
Old 09-02-2011, 04:44 PM   #5
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by John VV View Post
rkhunter normally gives false positives on brand new 5 min. old installs
normally it is the /bin and /usr/bin links or a script that is used to launch the program .
Not sure I understand. But the question seems to be: should I be concerned that months later I am still getting the warnings? Any other Debian users getting similar warnings?
 
Old 09-02-2011, 05:37 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,675
Blog Entries: 54

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Quote:
Originally Posted by Peufelon View Post
I ran rkhunter --update and afterwards still got the warning
Auch. 'man rkhunter' tells you that "--update" is for checking for online updates and "--propupd" for updating its data file of stored values.


Quote:
Originally Posted by Peufelon View Post
frankly you can be kinda scary when you become frustrated by my requests for advice/assistance.
Thanks for your candor.


Quote:
Originally Posted by Peufelon View Post
Anyway, I think you are saying that the warnings are probably innocuous, but that you can't be sure without getting the source code from the Debian repos. Or the binaries installed on my system?
What I'm trying to say is that warnings can only be judged innocuous after investigation. If the cause is an update then you will find the binaries' hashes match with those of a known good copy from a trusted repo mirror.
 
Old 09-02-2011, 06:35 PM   #7
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
So what precisely should I have done back in July?

Quote:
If the cause is an update then you will find the binaries' hashes match with those of a known good copy from a trusted repo mirror.
I think you are saying that what I should have done back in July is to download... the perl and curl binaries (?)... or a tarball with the source code?... from some Debian repository... perhaps using a live CD (?)... and check the hashes myself against what is given in the rkhunter log. Could you clarify?

Extra-Mile award to anyone who mentions the known genuine IP address of a specific Debian mirror as a double check. I have good reason to be constantly concerned about DNS hijacking and other surreptitious diversions. I know how to check using a remote server the IP address of what claims to be a Debian mirror... but what if my connection to that server is also diverted?

Cool, if I know how to check that the new hashes are valid, I now know how to update the rkhunter database. My bad for having overlooked that, and that's for pointing it out.

I recognize that you are potentially a source of useful information, so despite our chronic misunderstandings I value your advice, when I understand it.

Last edited by Peufelon; 09-02-2011 at 06:41 PM.
 
Old 09-02-2011, 07:40 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,675
Blog Entries: 54

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Quote:
Originally Posted by Peufelon View Post
download (..) perl and curl (..) from some Debian repository (..) and check the hashes myself against what is given in the rkhunter log.
Yes, you could have downloaded those packages from a known good repo mirror for comparison.
 
Old 09-03-2011, 04:05 PM   #9
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
I still don't understand what you advise

Well, at this point, who knows what might be a "known good" mirror? If kernel.org can be compromised, any mirror can be, eh?

OK, as my ordinary user I did
Code:
apt-get source curl
apt-get source perl
First surprise: my connections were torified, not neccessarily desirable in this case, but I did intend to torify downloads by my ordinary user (including, how ironic, via curl), so nice to know it sometmes works. When I upload or install as root my connections are not torified (by intention, so I can note the mirror from which I obtain each deb). That's useful to know!

The sha1 and sha256 sums given in the dsc files match the tarballs I downloaded as source. And the dsc files containing these hashes and other information are signed with GPG keys.

But the dsc signature files are not signed with any keys in the apt-keyring or any Debian keyrings or individual debian.org keys I had previously imported, and they did not belong to the persons designated as maintainers. After some digging, I found that
  • the curl dsc file is signed by Ramakrishnan Muthukrishnan, who really does have connections with debian.org, but the key in question is only self-signed! So maybe it's him, maybe not, who knows?
  • the perl dsc file is signed by Dominic Hargreaves, who really does have connections with debian.org, but not only is the key self-signed but some keys of (presumably) the real Hargreaves (which are signed by others) have been revoked! (Not expired.) So maybe it's him, maybe not, and maybe the revocations suggest that he takes crypto seriously as he should, and also seem to suggest that his comms may have been compromised previously, but who knows?

For what little it may be worth, the binaries I have in /usr/bin have these SHA1 and SHA256 hashes
Code:
9047c02726af368c84cabbe4ac26114a827932d2  perl
a1ca68d81cea4874d2291865075d3423460bad0a  curl
7576d163388b50b1b0f647e3cce30e901dfae97f7cd08f13f9a14c7cfb8aad91  perl
ae93d53cfd3edcf53b28ab8a14470ac8433519231fa8a7933c6e8eecb7bcdc7e  curl
So now what? Are you saying that I should try to compile (as my ordinary user) curl and perl and then check the hashes of these binaries? Is there any point to trying to chroot or jail that, given the fact that my root user already installed the "suspect" binaries? (Actually, maybe yes...)

And is anyone else worried by the fact that so many keys used to sign Debian related messages are self-signed only, even when the author has other valid keys which are signed by many others? (Maybe this is only a matter of convenience, and if I chase down the self signatures, I'll find that some of the keys used by the self-signing are ones signed by a dozens of others. Still, it seems to introduce another obstacle in the path of anyone who wants to check that the hashes are valid.)

Meanwhile, in my new and partially functional test installation of Squeeze on another PC, rkhunter is throwing up further warnings of the same kind.
 
Old 09-03-2011, 09:45 PM   #10
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
How silly of me

Of course, I need only compare the hashes mentioned in /var/log/rkhunter.log with those mentioned in the files
curl_7.18.2-8lenny5.dsc
perl_5.10.0-19lenny5.dsc
which I obtained by running apt-get source curl, perl. And I am glad to say that they do match, so indeed it appears that the explanation is that the debs were updated but rkhunter doesn't know what "Debian" is up to. Which just leaves the matter of verifying the signing keys.

So this is where things stand:
  • verified the current hashes against those given in the .dsc files (included with the source)
  • found the GPG keys used to sign the ,dsc files and verified the signatures
  • but still have some questions about the GPG keys used to sign the ,dsc files

And here's the procedure for investigating this kind of rkhunter warning for a binary such as /usr/bin/foo:
  • Code:
    apt-get source foo
  • unpack the tarballs and look at the foofile.dsc
  • try running
    Code:
    gpg --verify foofile.dsc
    (if it says "Good signature", you are done, but if the key used to sign isn't in your keyring, you'll get an erorr so in that case proceed)
  • search on-line to find the owner of the key and get it from a keyserver like http://keys.gnupg.net/
  • if you found a textfile holding the public key, import the key into your keyring using something like
    Code:
    gpg --import keyfile
  • try again
    Code:
    gpg --verify foofile.dsc
    (you should see "Good signature" from so and so, if so, you are done, if not, proceed)
  • if you get a bad signature, sound the alarm!

This answers another question I had: the hashes in the .dsc files refer to the binaries, so no need to compile.

Suggested improvement for apt-get: an argument which makes it just download the isc messages so that you can check this kind of thing without having to download the entire source.

Were it not for the recent news about kernel.org, I'd probably run the rkhunter command suggested by unspawn, but as things stand, I think I should look into those keys a bit more...

Oddly enough, if the key is authentic, rkhunter was complaining about binaries which incorporated security patches; the unpatched binaries were actually the ones unsafe for use. Unless I misunderstand something, rkhunter maintainers can't update their database until the other distros patch their curl and perl packages.

Last edited by Peufelon; 09-03-2011 at 10:29 PM.
 
Old 09-04-2011, 04:53 AM   #11
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,675
Blog Entries: 54

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Quote:
Originally Posted by Peufelon View Post
the explanation is that the debs were updated but rkhunter doesn't know what "Debian" is up to. \
Unless I misunderstand something, rkhunter maintainers can't update their database until the other distros patch their curl and perl packages.
The way RKH offered support for verifying files in 1.3.n differs from 1.2.n as there's no more downloadable hashes. (Maintenance of the 1.2.n hash files was a burden and community support was minimal enough for the feature to perform in a suboptimal way.) Now we leave responsibility for triggering hash updates to the user which is consistent with how say Samhain or Aide runs things. Updating hashes should be done only after verification using 0) a file integrity checker (never rely on one tool only) or 1) your distributions package management tools (that commonly means packages and not source packages).

I fear that your ability to diagnose and solve problems is complicated by your way of looking at things and with all due respect it can only be described as "convoluted".
 
Old 09-05-2011, 03:29 AM   #12
Peufelon
Member
 
Registered: Jul 2005
Posts: 164
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
If I gave misinformation in my previous post, please explain, clearly, what I said wrong.

If you think I gave bad advice, please explain, clearly, what you disagree with and why.

And if you're not capable of maintaining rkh, please pass it on to someone who can.
 
Old 09-05-2011, 02:02 PM   #13
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,675
Blog Entries: 54

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Quote:
Originally Posted by Peufelon View Post
If I gave misinformation in my previous post, please explain, clearly, what I said wrong.
If you think I gave bad advice, please explain, clearly, what you disagree with and why.
I said all that needed to be said and as clear as possible. I also advise against you phrasing things like that.


Quote:
Originally Posted by Peufelon View Post
And if you're not capable of maintaining rkh, please pass it on to someone who can.
..and given what I said earlier on it would embarrass me considerably to have to respond to such a statement in a way that distracts from the actual problem we here see evidence of.
 
  


Reply

Tags
debian repositories, kernel.org, rkhunter


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Security Breach at kernel.org GazL Linux - Security 47 10-14-2011 12:49 PM
LXer: Security breach on kernel.org LXer Syndicated Linux News 0 09-01-2011 01:31 AM
rkhunter warnings qwertyjjj Linux - Security 1 04-28-2011 05:05 AM
[SOLVED] rkhunter warnings skoinga Linux - Security 1 12-23-2010 11:49 AM
rkhunter warnings jantman Linux - Security 4 01-23-2007 03:39 PM


All times are GMT -5. The time now is 11:33 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration