Like Jackp27, I am reacting to a transient warning from rkhunter, indicating a possible LKM trojan, which may or may not be a false positive. Running chkrootkit and rkhunter repeatedly, including older versions running under live CDs like INSERT, indicated nothing wrong, but two runs of rkhunter running under the possibly compromised system itself did seem to suggest rkhunter thought it might have found elements of trojan code in RAM.

Like Jackp27, I can't give details right now because I do not currently have access to my logs, but I did find one webpage (can't give link because I do not currently have access to my detailed notes) suggesting that rkhunter may have thought it found a signature of the adore trojan in RAM by looking at /proc/kallsymms which is not a file I ordinary look at. I did look at it very closely yesterday, repeatedly, and it seems to be mostly empty, but occasionaly seems to contain what might be a sequence of calls to various kernel modules--- right now I only recall that some had the form ??_guest_? and that x_tables might be involved.

Can anyone give me a rough indication of what /proc/kallsymms is supposed to do, whether it should normally be empty, and when it is not, what kind of lines are supposed to show up in that "file" when I cat it? I also saw something about ?_logdrop? which may have had something to do with with rotating logs (I rebooted several times) rather than a trojan keylogger. But maybe some trojans rotate logs to try to hide their presence?

I know I am not giving enough information--- I hope to come back later with more details after I have managed to access my logs and notes, so feel free to say what kind of details would be most helpful in helping me decide whether or not this was a false positive.

Your issue is not even in the same ballpark.


Don't "hope" just do. No logs equals speculation.

I am having trouble accessing and even printing logs/notes... here is the best I can do right now:

rkhunter output (copied by hand)
Warning: Sebek LKM [WARNING]
Kernel symbol 'adore or sebek' found

Log file contained (copied by hand):
Checking for Sebek LKM...
Checking for kernel symbol 'adore or sebek' [Found]
Kernel symbol 'adore or sebek' found

At a thread from years ago in some forum (maybe this one) discussing a similar rkhunter warning, I found I should look at the file /proc/kallsymms, and this is usually empty now (is that normal) but sometimes contains some 478 pages. I know very little about the inner workings but I do know this is a virtual file containing information about the system. When it is not empty it almost looks like a memory map; starts (copied by hand)
Module Size Used by
ppdev 6468 0
....

I could not find string "sbk" or "adore" in this file. I did find sys_read which appears to be normal in itself. If this file really is a memory map it might be possible to check whether size of alleged sys_read which I think is a library call sounds correct--- I think the trojaned version differs by one library call from the real McCoy.

Some ideas about possible causes (remove coffee from vicinity of keyboard before continuing):

• While distracted I might have been running (as root)
  
  Code:

  tripwire --check --interactive
  rkhunter --checkall
  chkrootkit

  Tried to reproduce condition and failed but was able to get chkrootkit to report hidden processes while simultaneously running rkhunter, so maybe it is possible.
• for some reason I thought it would be a good idea to take my LAN off the web and do some penetration testing of my machine; I threw scuzzers and some very old sql injection exploits at it... and I forgot that pounding on it from INSIDE my little LAN is not the same as an outsider trying to crash through my firewall... and it was about this time that I had some funny indications that something was trying to download something but (I hope) being foiled by my firewall. So Aaron has already lost his crown as Doofus of the Year... after taking it a few days previously from Julian post Daniel.

Moral: don't do pentests on your own box...

Accidental but suggestive innuendo? Noted. Ow.

...but nothing should be withholding you from using your favorite search engine to look up say "ksyms vs kallsyms".


"Checking for kernel symbol 'adore or sebek'" is the actual message so if you grep for "sbk" then you won't find any "sebek" strings.


Not relying on a singel tool is a Good Thing but IIRC the Chkrootkit hidden processes test differs from looking for Adore or Sebek LKM traces. That said I haven't heard of recent cases involving Adore or Sebek anyway and I doubt it would even work with recent kernels. That is not to say I like saying "don't worry" or shrug things of otherwise: integrity verification, checking auth data and logs always trump making decisions based on fuzzy strings (as in what a user says he thinks he remembers he sort of might have seen. Maybe.).


On the contrary. There is nothing wrong with testing your second line of defense and not relying on only your router to ward off evil.


Computing is simple: a system is secured or it isn't. A process exists or it doesn't. An account was logged into or it wasn't. Test conditions and you see there is never any need to speak of (or worse base decisions on) "hope", "worry" or "think".

I did search and found only stuff which appears to be possibly unrelated, concerning a command which is spelt slightly differently, whereas I am asking about a FILE in the proc directory, /proc/kallsymms. If they -are- related, I couldn't find any information saying so, but that could be a hopeful sign, since I think the command sounds like the kind of thing chkrootkit might do, so it might have been an interaction between the two after all.

Of course I would poke around and test and check some more today (as I did past few days), but this would destroy all the work I did today to build a temporary semi-system using a live CD. Until I feel confidence in my old system I am not using it, so I currently cannot do many things I would otherwise be able to do, at least not easily. Today I am posting and reading and surfing, tommorrow back to off-line exploration. If that doesn't make sense to you, well, it makes sense to me.

I did check all my logs first thing, of course, but unfortunately they didn't tell me anything yay or nay. They might tell someone who knows more than I do quite a bit, so if anyone has any hints for my next round of studying my oldstable system, please speak up. In any case, I had difficulty in printing them or even copying them to a file, and I could hardly copy by hand 427 pages.

I am surprised by your claim that a system is either secure or not. In theory that is of course true, but I always understood that everyone knows that in practice, security is a process, not an achievable state.

Unspawn, you were correct: the file in question is called /proc/kallsyms (one "m" not two), and from little what I could find, it is in fact related to the command ksyms which makes a table of kernel symbols. As far as I can guess, this file is created by rkhunter while running its check, which is why I only see it nonempty when rkhunter is running. My best guess is that the transient warning was a false positive caused by inadvertently running rkhunter, chkrootkit, and tripwire all at the same time.

I think I forgot to say that live CDs found no evidence on disk of keyloggers or other suspicious files. The question remains about possible hidden kernel modules but I guess that would be fixed by reinstalling from scratch.

Does anyone have any advice for anything specific I should try to check in a specific log file?

"Think", "might": maybe yours but that's not my style of determining things.


...and that's why I asked you to post them.


What's the problem then?


You're misunderstanding what I'm trying to convey. In short it amounts to "to know things is to test things". That has nothing to do with the "security is a continuous process" mantra as you link it up to what I have said. Besides that I'm always cautious when people say "I'm surprised" as that state usually can be contributed to the (understanding of the) observer, not the situation itself.



Hell no it isn't. If you did research you would have found kallsyms is the 2.6 replacement of the 2.4 kernel ksysms.


In the years we've been working on RKH we've never heard of an account like that but it is something one could test.


If you have not (ever) ran publicly accessible services and if you are the only person to have access to the machine and if the login records and system and daemon logs show no access by others and if running whatever integrity verification software you run shows no sign of trouble that would leave you with an infinitesimal risk if you chalk this up as a false positive...