Hello List
program < rkhunter > shows possible rootkit , with messages as follow :
Starting test name 'running_procs' [19:02:43] Checking running processes for suspicious files [ Warning ] [19:02:43] Warning: The following processes are using suspicious files: [19:02:44] Command: cron [19:02:44] UID: 0 PID: 3191 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: cron [19:02:44] UID: 0 PID: 24469 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: egrep [19:02:44] UID: 0 PID: 19756 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: rkhunter [19:02:44] UID: 0 PID: 24855 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: run-crons [19:02:44] UID: 0 PID: 24471 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: sh [19:02:44] UID: 0 PID: 24470 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: sort [19:02:44] UID: 0 PID: 19757
.................
what prudent steps should one take to see if rootkit exists ?
...........
thanks best regards Ellan
* ellanios82 ellanios82@gmail.com [01-03-13 07:31]:
program < rkhunter > shows possible rootkit , with messages as follow :
Starting test name 'running_procs' [19:02:43] Checking running processes for suspicious files [ Warning ] [19:02:43] Warning: The following processes are using suspicious files: [19:02:44] Command: cron [19:02:44] UID: 0 PID: 3191 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: cron [19:02:44] UID: 0 PID: 24469
[...]
what prudent steps should one take to see if rootkit exists ?
On Thu, Jan 3, 2013 at 7:27 AM, ellanios82 ellanios82@gmail.com wrote:
Hello List
program < rkhunter > shows possible rootkit , with messages as follow :
Starting test name 'running_procs' [19:02:43] Checking running processes for suspicious files [ Warning ] [19:02:43] Warning: The following processes are using suspicious files: [19:02:44] Command: cron [19:02:44] UID: 0 PID: 3191 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: cron [19:02:44] UID: 0 PID: 24469 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: egrep [19:02:44] UID: 0 PID: 19756 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: rkhunter [19:02:44] UID: 0 PID: 24855 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: run-crons [19:02:44] UID: 0 PID: 24471 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: sh [19:02:44] UID: 0 PID: 24470 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [19:02:44] Command: sort [19:02:44] UID: 0 PID: 19757
.................
what prudent steps should one take to see if rootkit exists ?
In general:
- Manually inspect the file, is it clearly innocuous? - look at its permissions, does it have the substitute user or group bits set - Get it's MD5, SHA1 and SHA-256 hash. (use md5sum, sha1sum, and sha256sum respectively) - Google search for the error messages and the hash values. - if the suspicious file has contents, submit it to www.virustotal.com for analysis (free). - run strings against the file, do you see strange strings in there
Greg
On 01/03/2013 05:37 PM, Greg Freemyer wrote:
In general:
- Manually inspect the file, is it clearly innocuous?
- look at its permissions, does it have the substitute user or group bits set
- Get it's MD5, SHA1 and SHA-256 hash. (use md5sum, sha1sum, and
sha256sum respectively)
- Google search for the error messages and the hash values.
- if the suspicious file has contents, submit it towww.virustotal.com
for analysis (free).
- run strings against the file, do you see strange strings in there
______________
- thank you so much Greg - as an old-age home-user, this is way above my reach ................
/etc/crontab looks innocent :
< PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin MAILTO=root # # check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly # -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/
................
and, thank you for not saying "rtfm"
............
thanks best regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: alpine.LNX.2.00.1301032354190.9182@minas-tirith.valinor
El 2013-01-03 a las 17:57 +0200, ellanios82 escribió:
- thank you so much Greg
- as an old-age home-user, this is way above my reach
................
...
and, thank you for not saying "rtfm"
Thus, in the end, both rkhunter and chkrootkit are useless tools. You can not trust what they say: they say "wolf" on inocent files, thus when they really see the wolf nobody will believe them.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
On 01/04/2013 12:55 AM, Carlos E. R. wrote:
Thus, in the end, both rkhunter and chkrootkit are useless tools. You can not trust what they say: they say "wolf" on inocent files, thus when they really see the wolf nobody will believe them.
__________________
- & because Linux is so important in big-machines and Servers worldwide . . . suppose we must fear that sophisticated Stuxnet-type rootkits will emerge.
best regards
* ellanios82 ellanios82@gmail.com [01-04-13 02:59]:
On 01/04/2013 12:55 AM, Carlos E. R. wrote:
Thus, in the end, both rkhunter and chkrootkit are useless tools. You can not trust what they say: they say "wolf" on inocent files, thus when they really see the wolf nobody will believe them.
- & because Linux is so important in big-machines and Servers worldwide . .
. suppose we must fear that sophisticated Stuxnet-type rootkits will emerge.
I do not understand your position. You have a tool which you cannot understand it's operation (and cannot be bothered to try) and profess it's importance on "big iron".
And "rtfm" is not a bad thing, especially when you have results you do not understand from an improperly utilized tool.
Everything is *not* as it appears!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-01-04 a las 08:09 -0500, Patrick Shanahan escribió:
I do not understand your position. You have a tool which you cannot understand it's operation (and cannot be bothered to try) and profess it's importance on "big iron".
I would hope that a package distributed by openSUSE to work correctly out of the box, with no false possitives.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
* Carlos E. R. robin.listas@telefonica.net [01-04-13 08:22]:
El 2013-01-04 a las 08:09 -0500, Patrick Shanahan escribió:
I do not understand your position. You have a tool which you cannot understand it's operation (and cannot be bothered to try) and profess it's importance on "big iron".
I would hope that a package distributed by openSUSE to work correctly out of the box, with no false possitives.
The problem does not lie with the distribution but with the lack of proper user operation.
I don't use it but find from google that it is necessary to update rkhunter's local configs when local software is changed, ie: sudo rkhunter --propupd
see: https://help.ubuntu.com/community/RKhunter
The cite is for *buntu. Lacking concern/interest I didn't look further.
** rtfm is of particular importance when complex configuration is req'd, ** especially when not obvious.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-01-04 a las 08:32 -0500, Patrick Shanahan escribió:
The problem does not lie with the distribution but with the lack of proper user operation.
I don't use it but find from google that it is necessary to update rkhunter's local configs when local software is changed, ie: sudo rkhunter --propupd
Too complicated. I don't even try to run those things because of the complexity and false positives out of the box.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
Carlos E. R. said the following on 01/04/2013 08:19 AM:
El 2013-01-04 a las 08:09 -0500, Patrick Shanahan escribió:
I do not understand your position. You have a tool which you cannot understand it's operation (and cannot be bothered to try) and profess it's importance on "big iron".
I would hope that a package distributed by openSUSE to work correctly out of the box, with no false possitives.
Ah, right, the world of absolutes.
So, remove spamassassin and clamv. They are both going to produce false positives. And lets not bother doing risk analysis since its _only_ probabilistic and _might_ be wrong _sometimes_. Sort of like predicting the outcome of elections, eh?
While we're about it, I'd love to have software that works "correctly" for *MY* definition of correctly (as opposed to the developers) and is *absolutely* bug free and never crashes no matter what input I give it or hardware I run it on.
So once we start removing packages that don't meet your (and my) criteria we're not going to have a lot left.
Welcome to the world of absolutes. Such worlds are often populated by religious extremists, so I think I'll live with uncertainties and flaws, thank you.
On 01/03/2013 05:37 PM, Greg Freemyer wrote:
In general: - Manually inspect the file, is it clearly innocuous? - look at its permissions, does it have the substitute user or group bits set - Get it's MD5, SHA1 and SHA-256 hash. (use md5sum, sha1sum, and sha256sum respectively) - Google search for the error messages and the hash values. - if the suspicious file has contents, submit it to www.virustotal.com for analysis (free). - run strings against the file, do you see strange strings in there - Greg
______________________
- excuse my lack of knowledge . . . can you please give an example of how to use and compare MD5 sums for the purpose of rootkit forensics ??
thanks best regards Ellan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-01-04 a las 09:20 +0200, ellanios82 escribió:
- excuse my lack of knowledge . . . can you please give an example of how to
use and compare MD5 sums for the purpose of rootkit forensics ??
There is a technique by which you record signatures of files at a time when you know they are correct, and later you compare them to see there was no modification. Used properly it is very reliable.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
Carlos E. R. said the following on 01/04/2013 08:21 AM:
El 2013-01-04 a las 09:20 +0200, ellanios82 escribió:
- excuse my lack of knowledge . . . can you please give an example of how to
use and compare MD5 sums for the purpose of rootkit forensics ??
There is a technique by which you record signatures of files at a time when you know they are correct, and later you compare them to see there was no modification. Used properly it is very reliable.
For example, tripwire http://linux.about.com/cs/linux101/g/tripwire.htm which has been around for a long time (over 20 years) and has a commercial counterpart for the Big Iron folk who need a commercial/supported version.
http://en.wikipedia.org/wiki/Open_Source_Tripwire http://www.tripwire.com/
Of course you can always find ways to mount the system read only :-) (Mind you, that was easier before root and usr were merged!)
"Carlos E. R." robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-01-04 a las 09:20 +0200, ellanios82 escribió:
- excuse my lack of knowledge . . . can you please give an example of
how to
use and compare MD5 sums for the purpose of rootkit forensics ??
There is a technique by which you record signatures of files at a time when you know they are correct, and later you compare them to see there
was no modification. Used properly it is very reliable.
Cheers
(Carlos, can you change that to just "-- " before cheers. That's the standard that signifies start of signature. K9 at a minimum will cutoff signatures on replies if they have dash dash space on the line at the top of the signature.)
What Carlos describes is an auditing feature. There is a recommended auditing tool in the security repo, but I don't recall the name. I haven't used it.
Tripwire used to be the recommended tool, but no longer is. Google "opensuse tripwire" and you can probably find a sentence naming the new tool.
Greg
Greg Freemyer said the following on 01/04/2013 08:56 AM:
Tripwire used to be the recommended tool, but no longer is. Google "opensuse tripwire" and you can probably find a sentence naming the new tool.
You are thinking of AIDE, which is a IDS. Yes, there has been a move to checking things "on internet time" - aka real time.
In the commercial environments (banks, brokerages, insurance) there are many tools that are used. And don't forget that those environments have to deal with social as well as technical attacks, fraud, phising and so forth.
On Fri, Jan 4, 2013 at 9:06 AM, Anton Aylward opensuse@antonaylward.com wrote:
Greg Freemyer said the following on 01/04/2013 08:56 AM:
Tripwire used to be the recommended tool, but no longer is. Google "opensuse tripwire" and you can probably find a sentence naming the new tool.
You are thinking of AIDE, which is a IDS.
You're correct. Here's the opensuse doc for anyone that cares: http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/cha.ai...
As to the original question, note these configuration options:
md5 - Check if the md5 checksum of the file has changed. sha1 - Check if the sha1 (160 Bit) checksum of the file has changed.
So one of the things malicious people/software do is replace important files. By monitoring for changes of those 2 it lets you know when a has changed.
fyi: md5 is known to be cracked. It is relatively easy to take any random file that has enough "dead" space and have a program manipulate that dead space to force an overall md5. I am not aware of a similar issue with sha1. I recommend using both methods simultaneously. I doubt it will ever be possible to manipulate a file to match both a given md5 and a given sha-1 simultaneously.
Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: alpine.LNX.2.00.1301041505050.9182@minas-tirith.valinor
El 2013-01-04 a las 08:56 -0500, Greg Freemyer escribió:
Cheers
(Carlos, can you change that to just "-- " before cheers. That's the standard that signifies start of signature. K9 at a minimum will cutoff signatures on replies if they have dash dash space on the line at the top of the signature.)
No, that's your mail client not recognizing the PGP armour. In that case the double dash that I wrote is changed to what you see, it is correct.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
On Fri, Jan 4, 2013 at 10:02 AM, Carlos E. R. robin.listas@telefonica.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: alpine.LNX.2.00.1301041505050.9182@minas-tirith.valinor
El 2013-01-04 a las 08:56 -0500, Greg Freemyer escribió:
Cheers
(Carlos, can you change that to just "-- " before cheers. That's the standard that signifies start of signature. K9 at a minimum will cutoff signatures on replies if they have dash dash space on the line at the top of the signature.)
No, that's your mail client not recognizing the PGP armour. In that case the double dash that I wrote is changed to what you see, it is correct.
- -- Cheers
That's just plain annoying.
Most email clients don't handle dash-dash-space-newline, so I doubt many at all handle dash-space-dash-dash-newline. I know K-9 on my android doesn't.
fyi: at least in the above you don't have a newline after "- --". Is that not supposed to be part of it too?
Greg
El 2013-01-04 a las 16:36 -0500, Greg Freemyer escribió:
That's just plain annoying.
Most email clients don't handle dash-dash-space-newline, so I doubt many at all handle dash-space-dash-dash-newline. I know K-9 on my android doesn't.
Well, it is standard, defined I don't know where. When a PGP signature is added to an email, the signature separator has to be changed for some reason (I don't remember which), and the receiver has to decode the signature and change the separator back to the '-- NL" thing.
Not all MUAS are PGP aware. For example, gmail web client doesn't.
fyi: at least in the above you don't have a newline after "- --". Is that not supposed to be part of it too?
The one I sent had the new line, I'm sure.
This post I send without PGP part so that you can see how I send them.
On 2013-01-05 02:13 (GMT+0100) Carlos E. R. composed:
Greg Freemyer composed:
Most email clients don't handle dash-dash-space-newline,
Why do you think that?
Most in number wouldn't matter much if the most widely used in post volume do.
Well, it is standard, defined I don't know where.
http://tools.ietf.org/html/rfc3676#section-4.3 maybe?
* Felix Miata mrmazda@earthlink.net [01-04-13 20:38]:
On 2013-01-05 02:13 (GMT+0100) Carlos E. R. composed:
Greg Freemyer composed:
Most email clients don't handle dash-dash-space-newline,
Why do you think that?
Most in number wouldn't matter much if the most widely used in post volume do.
Well, it is standard, defined I don't know where.
or perhaps: rfc2440 (the OpenPGP standard), see section 7.1
* Carlos E. R. robin.listas@telefonica.net [01-01-70 12:34]:
El 2013-01-04 a las 16:36 -0500, Greg Freemyer escribió:
That's just plain annoying.
Most email clients don't handle dash-dash-space-newline, so I doubt many at all handle dash-space-dash-dash-newline. I know K-9 on my android doesn't.
Well, it is standard, defined I don't know where. When a PGP signature is added to an email, the signature separator has to be changed for some reason (I don't remember which), and the receiver has to decode the signature and change the separator back to the '-- NL" thing.
Not all MUAS are PGP aware. For example, gmail web client doesn't.
perhaps: rfc2440 (the OpenPGP standard), see section 7.1
On Fri, Jan 4, 2013 at 8:13 PM, Carlos E. R. robin.listas@telefonica.net wrote:
El 2013-01-04 a las 16:36 -0500, Greg Freemyer escribió:
That's just plain annoying.
Most email clients don't handle dash-dash-space-newline, so I doubt many at all handle dash-space-dash-dash-newline. I know K-9 on my android doesn't.
Well, it is standard, defined I don't know where. When a PGP signature is added to an email, the signature separator has to be changed for some reason (I don't remember which), and the receiver has to decode the signature and change the separator back to the '-- NL" thing.
Not all MUAS are PGP aware. For example, gmail web client doesn't.
fyi: at least in the above you don't have a newline after "- --". Is that not supposed to be part of it too?
The one I sent had the new line, I'm sure.
This post I send without PGP part so that you can see how I send them.
-- Cheers
Carlos,
The PGP ones were fine, but the above is wrong I think.
That is showing up as dash-dash-newline. The RFC standard is dash-dash-space-newline I do believe.
Greg
On Sun, 6 Jan 2013 16:02:41 -0500 Greg Freemyer greg.freemyer@gmail.com wrote:
That is showing up as dash-dash-newline. The RFC standard is dash-dash-space-newline I do believe.
Unless it's been updated or my memory is faulty, I could have sworn the standard is 'space dash dash' as seen in Carlos' lines, here:
-- Cheers
Carl Hartung wrote:
Unless it's been updated or my memory is faulty, I could have sworn the standard is 'space dash dash' as seen in Carlos' lines, here:
From RFC3676 https://www.ietf.org/rfc/rfc3676.txt
4.3. Usenet Signature Convention
There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed.
On Sun, 06 Jan 2013 16:32:55 -0500 James Knott james.knott@rogers.com wrote:
Carl Hartung wrote:
Unless it's been updated or my memory is faulty, I could have sworn the standard is 'space dash dash' as seen in Carlos' lines, here:
From RFC3676 https://www.ietf.org/rfc/rfc3676.txt
4.3. Usenet Signature Convention
There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted andstuffed) line consisting of DASH DASH SP is neither fixed nor flowed.
Thanks James,
*This* refreshed my memory as to my /purpose/ for having messed with it in the first place, years ago. Some email clients *claimed* to be using "plain text" when the box was ticked but, instead, were using 'format flowed' text, which broke the parsing of the delimiter in certain cases. This was quite a while ago.
regards,
Carl
Faulty memory ;-)
Sorry! I should have looked at the sig for my other accounts before chiming in. It's 'dash dash space'
Carl
On Sun, 6 Jan 2013 16:24:27 -0500 Carl Hartung opensuse@cehartung.com wrote:
Faulty memory ;-)
Sorry! I should have looked at the sig for my other accounts before chiming in. It's 'dash dash space'
Carl
Ah here are my old notes "must be delimited from the body of the message by a single line consisting of exactly two hyphens, followed by a space, followed by the end of line (i.e., "-- \n")."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-01-06 a las 16:02 -0500, Greg Freemyer escribió:
This post I send without PGP part so that you can see how I send them.
-- Cheers
Carlos,
The PGP ones were fine, but the above is wrong I think.
That is showing up as dash-dash-newline. The RFC standard is dash-dash-space-newline I do believe.
And indeed my email it has dash-dash-space-newline.
I saved it to a file, and then used hexdump to look at the file. See the signature line:
00000490 65 6d 2e 0a 0a 2d 2d 20 0a 43 68 65 65 72 73 0a |em...-- .Cheers.|
"0a 2d 2d 20 0a" is the exact sequence. Your MUA must be broken, and Alpine is known to be (almost?) a reference implementation of all standards. I would doubt very much that it does broken signatures.
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
Carlos E. R. wrote:
El 2013-01-06 a las 16:02 -0500, Greg Freemyer escribió:
This post I send without PGP part so that you can see how I send them.
-- Cheers
Carlos,
The PGP ones were fine, but the above is wrong I think.
That is showing up as dash-dash-newline. The RFC standard is dash-dash-space-newline I do believe.
My MUA shows me --=20 when I look at the source
And indeed my email it has dash-dash-space-newline.
I saved it to a file, and then used hexdump to look at the file. See the signature line:
00000490 65 6d 2e 0a 0a 2d 2d 20 0a 43 68 65 65 72 73 0a |em...-- .Cheers.|
"0a 2d 2d 20 0a" is the exact sequence. Your MUA must be broken, and Alpine is known to be (almost?) a reference implementation of all standards. I would doubt very much that it does broken signatures.
AFAIK, line-endings should be CRLF, not just LF.
(I have no idea what my MUA sends, though! :)
On 2013-01-07 10:39 (GMT) Dave Howorth composed:
AFAIK, line-endings should be CRLF
Correct, if you're running DOS, OS/2 or Windows, not if Mac or Linux. Man dos2unix.
On Mon, Jan 7, 2013 at 4:56 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2013-01-07 10:39 (GMT) Dave Howorth composed:
AFAIK, line-endings should be CRLF
Correct, if you're running DOS, OS/2 or Windows, not if Mac or Linux. Man dos2unix.
And correct if you're using email, regardless of platform. Man RFC 822:
2.1. CRLF
The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.
-- Chris
Christofer C. Bell wrote:
On Mon, Jan 7, 2013 at 4:56 AM, Felix Miata mrmazda@earthlink.net wrote:
On 2013-01-07 10:39 (GMT) Dave Howorth composed:
AFAIK, line-endings should be CRLF
Correct, if you're running DOS, OS/2 or Windows, not if Mac or Linux. Man dos2unix.
And correct if you're using email, regardless of platform. Man RFC 822:
2.1. CRLF
The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.
Exactly. Wire protocols are not OS-dependent in general. Same for HTTP.
On 2013-01-07 05:15 (GMT-0600) Christofer C. Bell composed:
Felix Miata wrote:
On 2013-01-07 10:39 (GMT) Dave Howorth composed:
AFAIK, line-endings should be CRLF
Correct, if you're running DOS, OS/2 or Windows, not if Mac or Linux. Man dos2unix.
And correct if you're using email, regardless of platform. Man RFC 822:
I suppose that depends on what is meant by "using email".
2.1. CRLF
The term CRLF, in this set of documents, refers to the sequence of octets corresponding to the two US-ASCII characters CR (decimal value 13) and LF (decimal value 10) which, taken together, in this order, denote a line break in RFC 822 mail.
My Gecko mbox files only contain 0x0A to denote line breaks, as I would expect, consistent with the rest of the plain text files on the Linux native filesystem.
Then there are those web pages transported via smtp euphemistically called email as well. :-(
On Mon, 7 Jan 2013 05:15:58 -0600 "Christofer C. Bell" wrote: <snipped>
And correct if you're using email, regardless of platform. Man RFC 822:
<snipped> Not intending to be pedantic but 822 was superseded by 2822:
" ... This standard supersedes the one specified in Request For Comments (RFC) 822 ..."
http://www.ietf.org/rfc/rfc2822.txt
* Carl Hartung opensuse@cehartung.com [01-07-13 08:45]:
On Mon, 7 Jan 2013 05:15:58 -0600 "Christofer C. Bell" wrote:
<snipped> > And correct if you're using email, regardless of platform. Man RFC > 822: <snipped> Not intending to be pedantic but 822 was superseded by 2822:
" ... This standard supersedes the one specified in Request For Comments (RFC) 822 ..."
and proceeds to state:
2.1.1. Line Length Limits
There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
Carl Hartung wrote:
On Mon, 7 Jan 2013 05:15:58 -0600 "Christofer C. Bell" wrote:
<snipped> > And correct if you're using email, regardless of platform. Man RFC > 822: <snipped> Not intending to be pedantic but 822 was superseded by 2822:
" ... This standard supersedes the one specified in Request For Comments (RFC) 822 ..."
More pedantry - superceeded by RFC5322.
http://www.ietf.org/rfc/rfc5322.txt
On Mon, Jan 7, 2013 at 12:30 PM, Per Jessen per@computer.org wrote:
Carl Hartung wrote:
On Mon, 7 Jan 2013 05:15:58 -0600 "Christofer C. Bell" wrote:
<snipped> > And correct if you're using email, regardless of platform. Man RFC > 822: <snipped> Not intending to be pedantic but 822 was superseded by 2822:
" ... This standard supersedes the one specified in Request For Comments (RFC) 822 ..."
More pedantry - superceeded by RFC5322.
Please! I welcome pedantry! I find the RFCs a real pain to search through! Having these links archived in email for me will make it easier! ;-)
-- Chris
On Mon, 7 Jan 2013 12:32:30 -0600 "Christofer C. Bell" wrote:
On Mon, Jan 7, 2013 at 12:30 PM, Per Jessen per@computer.org wrote:
Carl Hartung wrote:
On Mon, 7 Jan 2013 05:15:58 -0600 "Christofer C. Bell" wrote:
<snipped> > And correct if you're using email, regardless of platform. Man > RFC 822: <snipped> Not intending to be pedantic but 822 was superseded by 2822:
" ... This standard supersedes the one specified in Request For Comments (RFC) 822 ..."
More pedantry - superceeded by RFC5322.
Please! I welcome pedantry! I find the RFCs a real pain to search through! Having these links archived in email for me will make it easier! ;-)
-- Chris
Thanks for the correction (and the laugh!) Happy 2013, Patrick, Per, Chris ... All!
Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: alpine.LNX.2.00.1301071451510.9182@minas-tirith.valinor
El 2013-01-07 a las 10:39 -0000, Dave Howorth escribió:
Carlos E. R. wrote:
My MUA shows me --=20 when I look at the source
Then someting in your chain of email is broken.
AFAIK, line-endings should be CRLF, not just LF.
When email is saved in mbox format, all CRLF are changed to just LF. I have this in an email from Mark Crispin to me, and you can trust his word on this (he wrote some of the email standards).
- -- Cheers
Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith))
ellanios82 ellanios82@gmail.com wrote:
On 01/03/2013 05:37 PM, Greg Freemyer wrote:
In general: - Manually inspect the file, is it clearly innocuous? - look at its permissions, does it have the substitute user or group bits set - Get it's MD5, SHA1 and SHA-256 hash. (use md5sum, sha1sum,
and sha256sum respectively) - Google search for the error messages
and
the hash values. - if the suspicious file has contents, submit it to www.virustotal.com for analysis (free). - run strings against the file, do you see strange strings in there - Greg
- excuse my lack of knowledge . . . can you please give an example of
how to use and compare MD5 sums for the purpose of rootkit forensics ??
Often malware is tracked and cataloged based on it's hash (md5, sha1, etc.)
From the command line "md5sum suspect_file" will give the the md5 hash of that file. It should be a fairly long seemingly useless number, but every copy of that file in the world should have the same hash.
Now take that number and google it. If it is a known malicious file, malware investigative professionals will have reported the hash in any reports they published about it, so you may find a description of the malware on the internet this way.
I always do this with md5, sha1, and sha256.
The above assumes the malware is known, the exact malicious file you found was used before. Often a simple recompile can change the hash, so bad guys will often recompile their malware and re-release it.
Thus the above is just a first step in identifying malware, but it is the standard first step.
Greg
Greg Freemyer said the following on 01/04/2013 08:31 AM:
Often malware is tracked and cataloged based on it's hash (md5, sha1, etc.)
From the command line "md5sum suspect_file" will give the the md5 hash of that file. It should be a fairly long seemingly useless number, but every copy of that file in the world should have the same hash.
Now take that number and google it. If it is a known malicious file, malware investigative professionals will have reported the hash in any reports they published about it, so you may find a description of the malware on the internet this way.
I always do this with md5, sha1, and sha256.
The above assumes the malware is known, the exact malicious file you found was used before. Often a simple recompile can change the hash, so bad guys will often recompile their malware and re-release it.
Thus the above is just a first step in identifying malware, but it is the standard first step.
Greg is correct, and there is an industry behind this, and it is, like so many things, keyed more to Windows and the problems with Windows than to UNIX/Linux and the more sensible designs we have.
My point here is that Greg is describing blacklisting. It is an 'everything that is not prohibited is allowed' approach to security, and you need to check to see if the file was on the prohibited list (malware). That list is long and, like AV signatures, always out of date.
The converse approach, whitelisting, is the stance whereby "everything that is not explicitly allowed is prohibited". What is allowed is a much smaller list. The "tripwire" approach follows this; you keep a checksum of the systems when it was first installed, of the known-to-be-good programs.
There are many variations on this latter approach. One not very common approach is to have all the installed programs cryptographically signed, and the OS checks the signature before running them. That was more suited to mainframes than the UNIX/Linux model since they tend to have fewer and longer running programs.
Just in case you think, you catched a real rootkit, then you have to assume, that some binaries like ls, strings, md5sum ... are changed. I've seen rootkits that gave perfect md5sums and the output of strings for the manipulated binaries were the same as the original.
Boot from CD/DVD and inspect your disk!
On 01/04/2013 02:31 PM, Greg Freemyer wrote:
ellanios82 ellanios82@gmail.com wrote:
On 01/03/2013 05:37 PM, Greg Freemyer wrote:
In general: - Manually inspect the file, is it clearly innocuous? - look at its permissions, does it have the substitute user or group bits set - Get it's MD5, SHA1 and SHA-256 hash. (use md5sum, sha1sum,
and sha256sum respectively) - Google search for the error messages
and
the hash values. - if the suspicious file has contents, submit it to www.virustotal.com for analysis (free). - run strings against the file, do you see strange strings in there - Greg
- excuse my lack of knowledge . . . can you please give an example of
how to use and compare MD5 sums for the purpose of rootkit forensics ??
Often malware is tracked and cataloged based on it's hash (md5, sha1, etc.)
From the command line "md5sum suspect_file" will give the the md5 hash of that file. It should be a fairly long seemingly useless number, but every copy of that file in the world should have the same hash.
Now take that number and google it. If it is a known malicious file, malware investigative professionals will have reported the hash in any reports they published about it, so you may find a description of the malware on the internet this way.
I always do this with md5, sha1, and sha256.
The above assumes the malware is known, the exact malicious file you found was used before. Often a simple recompile can change the hash, so bad guys will often recompile their malware and re-release it.
Thus the above is just a first step in identifying malware, but it is the standard first step.
Greg
On Sun, 2013-01-06 at 01:33 +0100, Florian Gleixner wrote:
Just in case you think, you catched a real rootkit, then you have to assume, that some binaries like ls, strings, md5sum ... are changed. I've seen rootkits that gave perfect md5sums and the output of strings for the manipulated binaries were the same as the original.
Boot from CD/DVD and inspect your disk!
If you boot from he original install-medium, it will most likely show that most of the packages are different. Unless you never performed an upgrade...
Hans
ellanios82 wrote:
Starting test name 'running_procs' [19:02:43] Checking running processes for suspicious files [ Warning ] [19:02:43] Warning: The following processes are using suspicious files: [19:02:44] Command: cron [19:02:44] UID: 0 PID: 3191 [19:02:44] Pathname: /etc/crontab [19:02:44] Possible Rootkit: Unknown rootkit [...] what prudent steps should one take to see if rootkit exists ?
this behavior can be seen as a bug in rkhunter. Recently I wrote an upstream bug report. The rkhunter developers already fixed the bug, but did not release an updated version.
http://sourceforge.net/tracker/?func=detail&atid=794187&aid=3591302&...
I have patched rkhunter on openSUSE build service. You can try the rkhunter package from my repository:
http://download.opensuse.org/repositories/home:/bjoernv:/branches:/security/...
/etc/crontab should not be reported as an "Unknown rootkit" with the updated package.
Greetings, Björn
-
Anton Aylward -
Bjoern Voigt -
Carl Hartung -
Carlos E. R. -
Christofer C. Bell -
Dave Howorth -
ellanios82 -
Felix Miata -
Florian Gleixner -
Greg Freemyer -
Hans Witvliet -
James Knott -
Patrick Shanahan -
Per Jessen