Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Alan McKinnon]

On Tuesday 10 August 2010 03:18:05 William Hubbs wrote:
> On Mon, Aug 09, 2010 at 05:30:40PM -0700, Kevin O'Gorman wrote:
> > On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman  
wrote:
> > > On 08/09/2010 01:08 PM, Robert Bridge wrote:
> > > > On Mon, Aug 9, 2010 at 8:09 PM, Mick  
wrote:
> > > >> There have been discussions on this list why sudo is a bad idea and
> > > >> sudo
> > > 
> > > on
> > > 
> > > >> *any* command is an even worse idea. You might as well be running
> > > 
> > > everything
> > > 
> > > >> as root, right?
> > > > 
> > > > sudo normally logs the command executed, and the account which
> > > > executes it, so while not relevant for single user systems, it STILL
> > > > has benefits over running as root.
> > > 
> > > ...excepting, of course, "sudo bash -l" which means you've given away
> > > the keys to the kingdom.
> > > 
> > > I actually prefer "sudo su -" -- as long as I'm giving it away!  :o)
> 
> Afaik, there is no reason for "sudo su -"  It should be either
> 
> su -
> 
> or, if you are using sudo,
> 
> sudo -i

So what is the difference between "sudo -i" and "sudo su -" then? Please be 
precise.


> The disadvantage of "su -" is that it requires the user to know the root
> password.  But, "sudo -i" does the same thing without requiring the user
> to know the root password.

You seem to have confused ideas about authentication and authorization. They 
are not the same thing and harder is not always better.

I have 100+ machines (all distinctly different) that my team runs and sudo is 
on all of them. They all have a root password but no-one knows it anymore, 
it's tucked away nice in the safe just in case the whole team dies in a plane 
crash.

Meanwhile, we know each user is authenticated - ssh let them in with the right 
key, which they managed to unlock. To run a command as root, they must re-
authenticate with their password (unused till this point) and then they can do 
their jobs. We also know that they are authorized - this is the entire point 
of /etc/sudoers and it has no other purpose than authorizing users to do 
things what, when and where.

Knowing a root password is simply a second factor of authentication. It might 
as well be their own password. Well-known root password opens a security can 
of worms anyway and you don;t want to do where that leads.

So tell me again why sudo su - is inherently bad? Other than three extra 
keystrokes that is? And what about sudo implementations that don't support -i?



-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: Rooted/compromised Gentoo, seeking advice [Solved?]

[Paul Hartman]

On Mon, Aug 9, 2010 at 11:25 AM, Paul Hartman
 wrote:
> Hi, today when working remotely I ran nethogs and noticed suspicious
> network traffic coming from my home gentoo box. It was very low
> traffic (less than 1KB/sec bandwidth usage) but according to nethogs
> it was between a root user process and various suspicious-looking
> ports on outside hosts in other countries that I have no business
> with. netstat didn't show anything, however, but when I ran chkrootkit
> told me that netstat was INFECTED. I immediately issued "shutdown -h
> now" and now I won't be able to take a further look at it until I get
> home and have physical access to the box. System uptime was a few
> months. It was last updated for installation of a 2.6.33 kernel
> (2.6.35 is out now).

Well, so far everything I'm seeing points to a false alarm. :) It
seems I may have overreacted due to my lack of understanding.

First, when I got home and inspected router settings I realized the
strange activity I saw earlier was happening on a port I had opened
for Vuze (the bittorrent client). Nethogs output was like this:

NetHogs version 0.7.0
PID USER PROGRAM  DEVSENT  RECEIVED
0 root ..7423-213.138.94.110:49971 0.032   0.038 KB/sec
0 root ..7423-72.191.172.228:54861 0.000   0.000 KB/sec
0 root ..00:17423-82.52.3.94:57635 0.000   0.000 KB/sec
0 root unknown TCP 0.000
0.000 KB/sec
TOTAL0.032   0.038 KB/sec

Based on my Googling tonight, it seems this may simply be how it
displays incoming connection attempts. I found a post on the Ubuntu
Launchpad site that is basically asking the same question:
https://answers.launchpad.net/ubuntu/+source/nethogs/+question/113880

I changed my designated port setting in Vuze, opened that port on my
firewall, and then waited a few minutes and sure enough this same kind
of "mystery traffic" started to appear on that port. So it would seem
to be innocent bittorrent traffic. Egg on my face.

Second, the problem of chkrootkit telling me "find" and "netstat" were
INFECTED, in big scary upper-case letters. The files appear to be
genuine, I checked and double-checked and they appear to be
legitimate. I re-emerged them and the files match and still fail the
test. After looking into how chkroot does its tests, it's simply
grepping the strings from the file. I have debugging info compiled
into everything on my system and perhaps that means the files are
quite a bit more chatty than usual when it comes to strings. The
damning strings that caused it to give me an INFECTED warning? (using
the pattern from chkrootkit's test)

/usr/bin/find: sharefile.h
/bin/netstat: sockaddr.h

To further test this false-positive theory, I stripped those two
binaries of debugging data and now they do not appear as INFECTED by
the test. If anyone else wants to compile net-tools or findutils with
debugging data and nostrip and then run chkrootkit to see what results
you get on these files, that would be quite helpful in confirming
this.

I then tried rkhunter. It gave me numerous warnings, but after
checking the log for details they all appear to be harmless (For
example, it warns that /usr/bin/ldd is a script, not a binary... as
far as I can tell, that is how it's supposed to be)

Next I ran app-forensics/lynis, which is a more general system
settings audit. Everything looked normal there, too.

I've audited all of my logs, bash history, etc and everything looks
fine. The logs are complete. I use metalog so I've got duplicate log
data in most cases, split up into different files and directories, and
they all match. I've checked the other computers/devices in the house
and don't see any signs of any funny business.

The router settings and activity all look normal as well. I already
had non-default password, telnet disabled, external admin interface
disabled, web interface disabled, etc. and the firmware is the latest
version, supposedly not vulnerable to the milw0rm attack so I think it
is secure as can be expected.

I've checked all servers & online services that allow me to view my
login history and I don't see any unusual activity.

At this point I feel pretty good that my box was not compromised and
it was only ignorance and panic on my part. To play it safe, I'm going
to leave it disconnected for tonight and do some monitoring tomorrow
with wireshark just to be absolutely sure there's nothing going on.
Wish me luck! :)

I am grateful to everyone for their ideas and suggestions, and I'm
definitely going to change my sudoers privileges and more importantly
my habits and assumptions. The grace period that William alluded to
(timestamp_timeout is what Google tells me) may help to relieve a bit
of the "pain" of having to type my password so often.

Thanks,
Paul

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Adam Carter]

> Alternatively I was running vulnerable/compromised software. My box
> has sshd running, root login in ssh is not allowed, and pubkey only
> logins (no passwords). It is behind a wireless router but port 22 is
> open and pointing to this box, and a few others needed by other
> applications. So I will check out which keys exist on the compromised
> machine and make sure I recognize them all. I'll also need to check
> the status of any other computer my key is stored on (a mix of linux &
> windows, and my mobile phone). Sigh...
>

Since you're sshd setup is pretty secure i'd look at other network services.
What else was running, and were there any servers that were only available
from the local net (or were less protected from connections from the local
net) than the Internet? That's the only case where a router compromise would
assist in attacking your gentoo box.

There have been some web browser based attacks that have come out against
routers recently. They run the attack on your browser (cross site scripting
IIRC) to get access to the web interface of the router because that is
typically not available via the Internet side interface. Then then run a
password guessing attack. Did your router have a strong password?

Re: [gentoo-user] kde-4.4.5 & Seamonkey weirdness

[Adam Carter]

> Ever since my upgrade to kde-4.4.5 my seamonkey windows
> sporadically go black, when I move the mouse away from
> them. Both the Web browser and the mail client do this
> sporadically. Headers, toolbars and where the text appears
> all sporadically get into the act.  Even just the "subject
> window of this message is affected. Today, the color is solid gray.
> The maligned behavior  always returns upon exiting  kde or even rebooting
> the
> system.
>
>
> Also the scroll bar seems extraordinarily slow and often
> buffers up my keystrokes to the point of aimlessly wandering
> back and forth ignoring any new input, until it's
> wandering dance is exhausted.
>
>
> recompiling loads of stuff, as we speed to see if
> it fixes the problem. Anyone got any hints on this?
> bugs.gentoo.org did not reveal any pearls of wisdom
> that I could find
>

Interesting - sounds similar to what i get - see my thread "Some corruption
after gnome 2.30". I rebuilt world and still have the problem. So
perhaps.there is something lower level than gnome/kde that causes this
issue.

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Keith Dart]

On Mon, 9 Aug 2010 18:07:15 -0500
Paul Hartman  wrote:

> I do hope I can find some evidence that leads me to the point of
> entry. It would set my mind at ease.

Please let us know. I'm really curious about this also. I hope it
wasn't a trojaned package in portage.

-- 
-- --
Keith Dart
=

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Indexer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 10/08/2010, at 11:44 AM, Frank Steinmetzger wrote:

> Am Dienstag, 10. August 2010 schrieb Paul Hartman:
> 
>> Typing that long password into sudo every time I ran a command was a
>> hassle
> 
> I’ve never used sudo, and never really liked the idea of it. In fact I’m 
> always amused and slightly annoyed by the sheer amount of sudo one can find 
> in 
> your typical ubuntu howto. ;-)
> 
> It’s one reason why I abstained from installing Truecrypt 6, because it 
> requires sudo (Yes I know, in default setup you can’t do much with it. It is 
> but an issue of principle). However, because I need root commands regularly 
> (for example to initiate the VPN to my uni’s WiFi), I usually have one tab in 
> Yakuake where I do a normal su once after login.
> 
> And for more safety on my part, I also use different prompts: red hostname 
> for 
> root console, green u...@hostname for nonroot.
> -- 
> Gruß | Greetings | Qapla'
> What’s right is right, otherwise it’d be wrong.

I hope you realise the use of "sudo -i" will give you a root shell just like 
su. The reason sudo is preferred is that it means between multiple 
administrators, you can eliminate the need for a shared password. sudo can also 
control who and what groups can access sudo, and even subsets of commands.

sudo also has a "grace timer" in which once you prove your identity with your 
password once, you can use sudo without a password for a period of time after 
that. This can also be canceled with sudo -k

In terms of system administration best practices, sudo is the way to go. You 
will see it used in all server administration tasks to escalate privileges, in 
a secure manner.

William Brown

pgp.mit.edu



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iQIcBAEBAgAGBQJMYLhgAAoJEHF16AnLoz6JhJ8QAL5SO5DRmcQ3wXLdtMZooACu
WT4qyfKBnfMqakLJlSWYOH6tuIoK/mVYpeCpQmjpTuKaE90tnLnngCOVnG7puyqG
LkPBNew3iOsO0JJcNzCcMiwWQ1C7d2hkSyNl48FVwBwaVgbPmWL6flPLxwHxdbU1
O2Kke8ku2dAVRTg9NdnPnTcc7y1h2/VYLwqSY10ybHS4I6a7YuhEIeGZtCqfEZ6d
0WkbUaU2IJFEVskR2pRV3Oh8FOgjW1XpYPzGrzQgpByghVgDxalFpC89g3xVw2ue
bbRZNcn6NfZnfS/ltsCLr0mzSkV9xUXtYJkSQWN2jZbXM5rr+5gQXk1CqYLeDkjS
4HFST6bFfUUl7KMlo/mfH7PSD3Coa1J/DwcZFM9xkMx/sTy/TDsQhG1Qgb5jSn4u
/TVYRwkvNj/KXBolDPcEQkZ6h35R8h9gGFRaW9u1+O2YyLC8uOyFUhd0iHNo0+s0
r4Q0wiwnY7I5CI2ZQ5h2blbYzqyvgSa43rYp3rho9cp4LktDKO2qfoIW/CV/0Q6r
NmWcuzaU17QTAQn8VL2SUfG0zqXgCI4NlQcU8iNnYFRGUTvdx4crjzrgIqYm2rc+
PbpFuLl4Uz000hsQYXWfy9hwIMbxilT4F9AOpKmyU392GZ/22WUvoMk2uhzt8aCf
w44gvZvW1e44buFM2L/z
=AR4J
-END PGP SIGNATURE-

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Frank Steinmetzger]

Am Dienstag, 10. August 2010 schrieb Paul Hartman:

> Typing that long password into sudo every time I ran a command was a
> hassle

I’ve never used sudo, and never really liked the idea of it. In fact I’m 
always amused and slightly annoyed by the sheer amount of sudo one can find in 
your typical ubuntu howto. ;-)

It’s one reason why I abstained from installing Truecrypt 6, because it 
requires sudo (Yes I know, in default setup you can’t do much with it. It is 
but an issue of principle). However, because I need root commands regularly 
(for example to initiate the VPN to my uni’s WiFi), I usually have one tab in 
Yakuake where I do a normal su once after login.

And for more safety on my part, I also use different prompts: red hostname for 
root console, green u...@hostname for nonroot.
-- 
Gruß | Greetings | Qapla'
What’s right is right, otherwise it’d be wrong.


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: GDBM incompatibility woes; any experts out there?

[Kevin O'Gorman]

On Mon, Aug 9, 2010 at 2:49 PM, walt  wrote:

> On 08/09/2010 12:33 PM, Kevin O'Gorman wrote:
>
> > ...
>
>  Now I find that not only
>> do the gdbm modules of python and perl reject my files, but so does a C
>> program that uses the distributed
>> libgdbm.
>>
>
> You didn't say how long ago the problem started, but looking at the
> files in sys-libs/gdbm I see nothing newer than March 20.  Is your
> problem newer than March 20?
>
> Have you tried running your test program with strace?
>
>
I hadn't done anything with that application in over a year, so I did not
have any way to narrow it down.
As it happens, I had a sudden rush of brains to the head and read the ewarn
message that comes out
when you compile gdbm, to the effect that 32-bit systems may have to
rebuild, etc, etc.

As I suspected, it was LFS-related.

Write it off as a case of RTFLog.

Now all I have to do is discover why an ewarn wasn't emailed to me -- I
thought I had that set up.

-- 
Kevin O'Gorman, PhD

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[William Hubbs]

On Mon, Aug 09, 2010 at 05:30:40PM -0700, Kevin O'Gorman wrote:
> On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman  wrote:
> 
> > On 08/09/2010 01:08 PM, Robert Bridge wrote:
> > > On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
> > >> There have been discussions on this list why sudo is a bad idea and sudo
> > on
> > >> *any* command is an even worse idea. You might as well be running
> > everything
> > >> as root, right?
> > >
> > > sudo normally logs the command executed, and the account which
> > > executes it, so while not relevant for single user systems, it STILL
> > > has benefits over running as root.
> >
> > ...excepting, of course, "sudo bash -l" which means you've given away
> > the keys to the kingdom.
> >
> > I actually prefer "sudo su -" -- as long as I'm giving it away!  :o)

Afaik, there is no reason for "sudo su -"  It should be either

su -

or, if you are using sudo, 

sudo -i

The disadvantage of "su -" is that it requires the user to know the root
password.  But, "sudo -i" does the same thing without requiring the user
to know the root password.

William

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Kevin O'Gorman]

On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman  wrote:

> On 08/09/2010 01:08 PM, Robert Bridge wrote:
> > On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
> >> There have been discussions on this list why sudo is a bad idea and sudo
> on
> >> *any* command is an even worse idea. You might as well be running
> everything
> >> as root, right?
> >
> > sudo normally logs the command executed, and the account which
> > executes it, so while not relevant for single user systems, it STILL
> > has benefits over running as root.
>
> ...excepting, of course, "sudo bash -l" which means you've given away
> the keys to the kingdom.
>
> I actually prefer "sudo su -" -- as long as I'm giving it away!  :o)


-- 
Kevin O'Gorman, PhD

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Paul Hartman]

On Mon, Aug 9, 2010 at 2:09 PM, Mick  wrote:
> On Monday 09 August 2010 17:25:56 Paul Hartman wrote:
>> My user account has sudo-without-password rights to any command.
>
> Ouch!
>

Having still not physically touched the machine yet, I don't know if
sudo had anything to do with it at all at this point. But I'll assume
for a moment that its use was perhaps involved...

> There have been discussions on this list why sudo is a bad idea and sudo on
> *any* command is an even worse idea. You might as well be running everything
> as root, right?

Essentially. I did not think it through from an internally-defensive
standpoint. I only thought of sudo as "I am deciding whether to run
this command as user or as root". Assuming *I* would be the only one
running a program on my computer. My thinking was clearly flawed
there... The idea of an attacker being in my system didn't really
enter my mind. Or an untrusted program shelling out and running "sudo
some-bad-stuff" without my knowing. Every sudo command is logged,
sure, but as Bill pointed out that only works for as long as it takes
someone to sudo himself into a root shell (or delete the logs). I
don't really audit the sudo logs regularly because of the stupid
assumption that I was the only one running any sudo commands.

> You have decided wisely to reinstall because you can't be sure of this OS
> anymore.

I'm most concerned about learning how this happened because I don't
want to reinstall everything only to be compromised again, and with
the hope that perhaps any info I find can help others avoid finding
themselves in this same situation. If I'm only going to re-create the
exact same set-up, I don't know if I can be sure of it then even after
reinstalling...

> Please keep us updated on what you find from the forensic analysis.

Sudo was one of the first things that popped into my head. sshd is
really the only service open to the outside. Some other ports are open
for specific apps, like bittorrent traffic, which is what I was
monitoring when I noticed the suspicious activity -- and I was
downloading a Linux ISO, I swear. My original plans for tonight were
to install Sabayon on an old laptop that is becoming unmanageable from
a Gentoo standpoint due to infrequent use and days-long update
sessions. I'll put that little project on hold for now...

My sshd setup is pubkey only, no root logins, and I use denyhosts to
block after 3 failed logins, and it syncs its blocklist from the
denyhosts master server many times a day. I use NX Server, but not
with the default key, and I don't think there have been any (publicly
disclosed) remotely-exploitable opensshd vulnerabilities that would
allow an attacker direct entry into a system. I haven't noticed
anything out of place on my system, no unusual files or missing items.
I take infrequent peeks at my ssh logs, w/who/last and network traffic
(as I did today when I discovered it), but I am not religious about
reading every log. Life has been quite busy lately and I haven't had
as much time to dedicate to that sort of stuff.  I has been more like
log on, check my email, pay my bills, log off.

So, from that outside-entry standpoint I was certainly lulled into a
false sense of security about my system. My root account has a very
long and complicated password, and my user account was surely
"impenetrable" since I was using pubkey-only SSH logins, right...  I
have encrypted partitions, but they are mounted when the system is up
and running, so they are really pointless against an "online"
attack...

Typing that long password into sudo every time I ran a command was a
hassle, and clearly I thought myself too intelligent to ever run a
malicious piece of code on my own computer. I mean, that's the kind of
thing I would never do. I'm careful. I usually look at things before I
run them, scan them with clamscan (not that I run outside
scripts/binaries very often at all). Right? And what if a
seemingly-safe program decided to download and run malware on its own?
What if there was a vulnerability that was exploited before it was
discovered & patched by the community (and my Gentoo update cycle)?
What if there was a rogue Firefox add-on stealing passwords or running
shell scripts? That would probably never happen, surely someone else
would have noticed it and put a stop to it before it got to me, or I
would have read a warning about it in the tech news someplace. Yeah,
I'm being a bit sarcastic here. ;)

I do hope I can find some evidence that leads me to the point of
entry. It would set my mind at ease.

[gentoo-user] gnome 2.30 and laptop

[William Kenworthy]

I have upgraded to gnome 2.30 and while there are a few rough edges, the
display is causing real problems.

When I am using a projector ("beamer" for the yanks here :) on external
vga and LCD at the same time, the screen sometimes treats the vga out as
a second screen (not a clone of the first which is what I want).  Its
random on how it happens.  Then if I start any application, Mr Murphy
will ensure it starts on the wrong output :)  I suspect running vmware
at some point before connecting the projector may have something to do
with it (has never happened unless I have run vmware sometime since
boot)

Earlier gnome (<=2.28) had a panel icon for managing the display but
this had dissappeared with 2.30.

so:
1. how can I manage the display from gnome 2.30
2. how can I fix the underlying problem of being cloned sometimes and
not others.
3. how can I do an emergency fix without having to restart X (maybe a
script/xrandr command if it exists?)
i.e., its somewhat disastrous to discover this at the start of a
presentation!)

BillK

-- 
William Kenworthy 
Home in Perth!

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Dale]

Mick wrote:

On Monday 09 August 2010 21:25:37 Dale wrote:
   

Robert Bridge wrote:
 

On Mon, Aug 9, 2010 at 8:09 PM, Mick   wrote:
   

There have been discussions on this list why sudo is a bad idea and sudo
on *any* command is an even worse idea. You might as well be running
everything as root, right?
 

sudo normally logs the command executed, and the account which
executes it, so while not relevant for single user systems, it STILL
has benefits over running as root.

RobbieAB
   

I don't use sudo here but I assume a admin would only know that a nasty
command has been ran well after it was ran?  Basically, after the damage
has been done, you can go look at the logs and see the mess some hacker
left behind.  For me, that isn't a whole lot of help.  You still got
hacked, you still got to reinstall and check to make sure anything you
copy over is not infected.

Assuming that they can erase dmesg, /var/log/messages and other log
files, whose to say the sudo logs aren't deleted too?  Then you still
have no records to look at.

I agree with the other posters tho, re-install from scratch and re-think
your security setup.
 

That's the problem with any compromise worth its salt, all logs will be
tampered to clear traces of interfering with your system.  Monitoring network
traffic from a healthy machine is a good way to establish suspicious activity
on the compromised box and it also helps checking for open ports (nmap, or
netcat) to find out what's happening to the compromised box.

   


Yep, cause when they are in the system, they can do what they want.  
Once they get root privileges, nothing else matters after that.  It's 
just a matter of the clean up which from what I have always read is a 
reinstall.  It's not good to hear but it's the best way to know for sure 
you are safe.


Me tho, I would start from scratch and not even chroot into the old 
install.  I might mount and try to read a log file or copy my world file 
but that would be about it.  I'm not sure I would trust anything else.   
I just hope this never happens to me.  :/


Dale

:-)  :-)

[gentoo-user] Re: GDBM incompatibility woes; any experts out there?

[walt]

On 08/09/2010 12:33 PM, Kevin O'Gorman wrote:

> ...

Now I find that not only
do the gdbm modules of python and perl reject my files, but so does a C program 
that uses the distributed
libgdbm.


You didn't say how long ago the problem started, but looking at the
files in sys-libs/gdbm I see nothing newer than March 20.  Is your
problem newer than March 20?

Have you tried running your test program with strace?

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Mick]

On Monday 09 August 2010 21:25:37 Dale wrote:
> Robert Bridge wrote:
> > On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
> >> There have been discussions on this list why sudo is a bad idea and sudo
> >> on *any* command is an even worse idea. You might as well be running
> >> everything as root, right?
> > 
> > sudo normally logs the command executed, and the account which
> > executes it, so while not relevant for single user systems, it STILL
> > has benefits over running as root.
> > 
> > RobbieAB
> 
> I don't use sudo here but I assume a admin would only know that a nasty
> command has been ran well after it was ran?  Basically, after the damage
> has been done, you can go look at the logs and see the mess some hacker
> left behind.  For me, that isn't a whole lot of help.  You still got
> hacked, you still got to reinstall and check to make sure anything you
> copy over is not infected.
> 
> Assuming that they can erase dmesg, /var/log/messages and other log
> files, whose to say the sudo logs aren't deleted too?  Then you still
> have no records to look at.
> 
> I agree with the other posters tho, re-install from scratch and re-think
> your security setup.

That's the problem with any compromise worth its salt, all logs will be 
tampered to clear traces of interfering with your system.  Monitoring network 
traffic from a healthy machine is a good way to establish suspicious activity 
on the compromised box and it also helps checking for open ports (nmap, or 
netcat) to find out what's happening to the compromised box.

-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Philip Webb]

100809 Robert Bridge wrote:
> On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
>> There have been discussions on this list why sudo is a bad idea
>> and sudo on *any* command is an even worse idea.
>> You might as well be running everything as root, right?
> sudo normally logs the command executed and the account which executes it,
> so while not relevant for single user systems,
> it STILL has benefits over running as root.

I follow  2  simple rules:
(1) never start X as root -- I open in a raw terminal, then 'startx',
so it's ok to login there as root to get some system fixes done,
but of course logout again before starting X as user --
& (2) do all system stuff in a virtual root terminal on its own desktop,
where the prompt says 'root' in red letters & the background is black
(my user terminal has a white background): that's down in the basement,
where all the pipes & wires are & you need a hard hat & safety boots
& you need to unlock the basement door, whose key is the root password.

also, my user terminal says :

  524: gx> which sudo
  which: no sudo in 
(/sbin:/usr/sbin:/usr/local/sbin::/bin:/usr/bin:/usr/local/bin:/usr/kde/3.5/bin)

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatchassdotutorontodotca

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Dale]

Robert Bridge wrote:

On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
   

There have been discussions on this list why sudo is a bad idea and sudo on
*any* command is an even worse idea. You might as well be running everything
as root, right?
 

sudo normally logs the command executed, and the account which
executes it, so while not relevant for single user systems, it STILL
has benefits over running as root.

RobbieAB

   


I don't use sudo here but I assume a admin would only know that a nasty 
command has been ran well after it was ran?  Basically, after the damage 
has been done, you can go look at the logs and see the mess some hacker 
left behind.  For me, that isn't a whole lot of help.  You still got 
hacked, you still got to reinstall and check to make sure anything you 
copy over is not infected.


Assuming that they can erase dmesg, /var/log/messages and other log 
files, whose to say the sudo logs aren't deleted too?  Then you still 
have no records to look at.


I agree with the other posters tho, re-install from scratch and re-think 
your security setup.


Dale

:-)  :-)

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Bill Longman]

On 08/09/2010 01:08 PM, Robert Bridge wrote:
> On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
>> There have been discussions on this list why sudo is a bad idea and sudo on
>> *any* command is an even worse idea. You might as well be running everything
>> as root, right?
> 
> sudo normally logs the command executed, and the account which
> executes it, so while not relevant for single user systems, it STILL
> has benefits over running as root.

...excepting, of course, "sudo bash -l" which means you've given away
the keys to the kingdom.

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Robert Bridge]

On Mon, Aug 9, 2010 at 8:09 PM, Mick  wrote:
> There have been discussions on this list why sudo is a bad idea and sudo on
> *any* command is an even worse idea. You might as well be running everything
> as root, right?

sudo normally logs the command executed, and the account which
executes it, so while not relevant for single user systems, it STILL
has benefits over running as root.

RobbieAB

Re: [gentoo-user] Re: Rooted/compromised Gentoo, seeking advice

[Mick]

On Monday 09 August 2010 19:59:11 7v5w7go9ub0o wrote:
> On 08/09/10 12:25, Paul Hartman wrote:
> []
> 
> > If anyone has advice on what I should look at forensically to
> > determine the cause of this, it is appreciated. I'll first dig into
> > the logs, bash history etc. and really hope that this very happened
> > recently.
> > 
> > Thanks for any tips and wish me good luck. :)
> 
> AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus
> signatures; you might scan your box with that. It has an on-access,
> realtime monitor option as well, which I use it to monitor anything
> downloaded and or compiled on my box (in case the distribution screen
> gets hacked).
> 
> 
> 
> Presuming you're rooted, you might first try their stand-alone, linux
> live-disk scanner so as to avoid borked kernel and/or core utilities:
> 
> 

Another idea to help with your forensics would be to bring a netstat and lsof 
binary over to your machine and run them to see which actors are running and 
trying to get out.  That could help you detect what is running on that machine 
and google your way from there.

You could also run rkhunter.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] kde-4.4.5 & Seamonkey weirdness

[James]

Hello,

Ever since my upgrade to kde-4.4.5 my seamonkey windows
sporadically go black, when I move the mouse away from 
them. Both the Web browser and the mail client do this
sporadically. Headers, toolbars and where the text appears
all sporadically get into the act.  Even just the "subject
window of this message is affected. Today, the color is solid gray.
The maligned behavior  always returns upon exiting  kde or even rebooting the
system.


Also the scroll bar seems extraordinarily slow and often
buffers up my keystrokes to the point of aimlessly wandering
back and forth ignoring any new input, until it's 
wandering dance is exhausted.


recompiling loads of stuff, as we speed to see if
it fixes the problem. Anyone got any hints on this?
bugs.gentoo.org did not reveal any pearls of wisdom
that I could find


ideas?
James

[gentoo-user] GDBM incompatibility woes; any experts out there?

[Kevin O'Gorman]

Around 2002, I started working on a project that involved a few simple
database tables, and I wanted it
simple, so I used python and the gdbm module.  Since then, all has been
well.  Now I find that not only
do the gdbm modules of python and perl reject my files, but so does a C
program that uses the distributed
libgdbm.

Okay, so you think I broke my files somehow.  I was afraid that was true, so
I used the gdbm source
I had in distfiles, configured it with default setup but did not install
it.  Instead I compiled it with my
C test program, and set out to find the problem in the data, more or less
expecting
to spend a long time in the debugger.  But lo and behold, it worked just
fine.  Now I'm suspecting that
the ebuild does something (Large File support?) to the GDBM that it didn't
used to do.

I did not know when I started how much configuration information I was going
to need, and so there's
a configuation database.  As it happens, I never put more than one record in
it, so it's perfect for
simple testing.  The database is called dbhex.control, and the single record
key is "control".  I've
attached it.

I used this Makefile, with no targets or rules, just to get the flags I
want: I have my testfile 'testgdbm.c' in
the same directory with the makefile, and a gdbm-1.8.3 directory.

I make testgdbm, run "testgdbm dbhex.control" and get exactly what I
should.  If I link against the
Gentoo gdbm distribution, I get error 22 "invalid argument".  Not knowing
much about ebuilds, I'm not sure
how to tell what has changed.

Can anybody help me with:
  1) why it fails now with Gentoo tools.
  2) the best way to get it working again, preferably with both python and
C.  I expect there's either
  a compatibility flag, or I may need to do a file conversion.  Overall,
my databases run to about
  3 gigabytes, so it's doable either way.

Thanks in advance for any help.

# Makefile for tests
CC=gcc
CFLAGS=-Wall -g -m32 -ansi
LDFLAGS=-m32 gdbm-1.8.3/global.o gdbm-1.8.3/gdbmopen.o
gdbm-1.8.3/gdbmerrno.o gdbm-1.8.3/gdbmclose.o gdbm-1.8.3/update.o
gdbm-1.8.3/falloc.o gdbm-1.8.3/bucket.o gdbm-1.8.3/gdbmfetch.o
gdbm-1.8.3/findkey.o gdbm-1.8.3/version.o gdbm-1.8.3/gdbmseq.o
gdbm-1.8.3/hash.o

My test file:

/**
 * @file
 *
 * Program to test minimal functionality of the gdbm library on a known gdbm
file.
 *
 * Last Modified: Mon Aug  9 12:01:32 PDT 2010
 * @author Kevin O'Gorman
 */

#include 
#include 
#include 
#include 
#include 
#include 

void
fatal(void) {
  fprintf(stderr, "Fatal function called\n");
  fprintf(stderr, "Errno is %d\n", errno);
  exit(EXIT_FAILURE);
}

/** The main thing.
 * @param argc the number of tokens on the input line.
 * @param argv an array of tokens.
 * @return 0 on success, 1-255 on failure
 */
int
main(int argc, char *argv[])
{
  datum key;
  datum value;
  datum nextkey;
  char longbucket[4096];

  printf("Running with GDBM: %s\n", gdbm_version);
  if (argc !=2) {
fprintf(stderr, "Usage:\n   %s filename\n", argv[0]);
exit(EXIT_FAILURE);
  }

  errno = 0;
  GDBM_FILE control = gdbm_open(argv[1], 1024, GDBM_READER, 0666, fatal);
  if (control == NULL) {
perror("gdbm");
fprintf(stderr, "Open returned NULL\n");
fprintf(stderr, "Errno is %d\n", errno);
exit(EXIT_FAILURE);
  }
  printf("is open\n");

  key = gdbm_firstkey(control);
  while (key.dptr) {
memcpy(longbucket, key.dptr, key.dsize);
longbucket[key.dsize] = '\0';
printf("Key: %s", longbucket);
value = gdbm_fetch(control, key);
memcpy(longbucket, value.dptr, value.dsize);
longbucket[value.dsize] = '\0';
printf(", val: \"%s\"\n", longbucket);
free(value.dptr);
nextkey = gdbm_nextkey(control, key);
free(key.dptr);
key = nextkey;
  }

  gdbm_close(control);
  printf("That's all, folks...\n");

  return EXIT_SUCCESS;
}

/* vim: set et ai sts=2 sw=2: */


-- 
Kevin O'Gorman, PhD


dbhex.control
Description: Binary data


Makefile
Description: Binary data
/**
 * @file
 *
 * Program to test minimal functionality of the gdbm library on a known gdbm file.
 *
 * Last Modified: Mon Aug  9 12:01:32 PDT 2010
 * @author Kevin O'Gorman
 */

#include 
#include 
#include 
#include 
#include 
#include 

#define DBFILE "dbgames/ogdb-"

void
fatal(void) {
  fprintf(stderr, "Fatal function called\n");
  fprintf(stderr, "Errno is %d\n", errno);
  exit(EXIT_FAILURE);
}

/** The main thing.
 * @param argc the number of tokens on the input line.
 * @param argv an array of tokens.
 * @return 0 on success, 1-255 on failure
 */
int
main(int argc, char *argv[])
{
  datum key;
  datum value;
  datum nextkey;
  char longbucket[4096];

  printf("Running with GDBM: %s\n", gdbm_version);
  if (argc !=2) {
fprintf(stderr, "Usage:\n   %s filename\n", argv[0]);
exit(EXIT_FAILURE);
  }

  errno = 0;
  GDBM_FILE control = gdbm_open(argv[1], 1024, GDBM_READER, 0666, fatal);
  if (control == NULL) {
perror("gdbm");
fprintf(stderr, "Open returned NULL\n");
fprintf(stderr, "Errno is %d\

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Mick]

On Monday 09 August 2010 17:25:56 Paul Hartman wrote:
> My user account has sudo-without-password rights to any command.

Ouch!

There have been discussions on this list why sudo is a bad idea and sudo on 
*any* command is an even worse idea. You might as well be running everything 
as root, right?

You have decided wisely to reinstall because you can't be sure of this OS 
anymore.

Please keep us updated on what you find from the forensic analysis.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Re: Rooted/compromised Gentoo, seeking advice

[Paul Hartman]

On Mon, Aug 9, 2010 at 1:59 PM, 7v5w7go9ub0o <7v5w7go9u...@gmail.com> wrote:
> On 08/09/10 12:25, Paul Hartman wrote:
> []
>> If anyone has advice on what I should look at forensically to
>> determine the cause of this, it is appreciated. I'll first dig into
>> the logs, bash history etc. and really hope that this very happened
>> recently.
>>
>> Thanks for any tips and wish me good luck. :)
>
> AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus
> signatures; you might scan your box with that. It has an on-access,
> realtime monitor option as well, which I use it to monitor anything
> downloaded and or compiled on my box (in case the distribution screen
> gets hacked).
>
> 
>
> Presuming you're rooted, you might first try their stand-alone, linux
> live-disk scanner so as to avoid borked kernel and/or core utilities:
>
> 

Was not aware of that one, I'll give it a try. Thanks.

[gentoo-user] Re: Rooted/compromised Gentoo, seeking advice

[7v5w7go9ub0o]

On 08/09/10 12:25, Paul Hartman wrote:
[]
> If anyone has advice on what I should look at forensically to
> determine the cause of this, it is appreciated. I'll first dig into
> the logs, bash history etc. and really hope that this very happened
> recently.
>
> Thanks for any tips and wish me good luck. :)

AntiVir (Avira) anti-malware scanner has hundreds of Linux rootkit/virus
signatures; you might scan your box with that. It has an on-access,
realtime monitor option as well, which I use it to monitor anything
downloaded and or compiled on my box (in case the distribution screen
gets hacked).



Presuming you're rooted, you might first try their stand-alone, linux
live-disk scanner so as to avoid borked kernel and/or core utilities:

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Paul Hartman]

On Mon, Aug 9, 2010 at 11:48 AM, Alan McKinnon  wrote:
> On Monday 09 August 2010 18:25:56 Paul Hartman wrote:
>> Hi, today when working remotely I ran nethogs and noticed suspicious
>> network traffic coming from my home gentoo box. It was very low
>> traffic (less than 1KB/sec bandwidth usage) but according to nethogs
>> it was between a root user process and various suspicious-looking
>> ports on outside hosts in other countries that I have no business
>> with. netstat didn't show anything, however, but when I ran chkrootkit
>> told me that netstat was INFECTED. I immediately issued "shutdown -h
>> now" and now I won't be able to take a further look at it until I get
>> home and have physical access to the box. System uptime was a few
>> months. It was last updated for installation of a 2.6.33 kernel
>> (2.6.35 is out now).
>>
>> I have 3 goals now:
>>
>> 1) Figure out what is running on my box and how long it has been there.
>> 2) Find out how it got there.
>> 3) Sanitizing, or most likely rebuilding the system from scratch.
>
> Here's the bad news:
>
> An intruder probably gained access through a script kiddie script, which has
> likely already removed all the logs. Or they have possibly been rotated away
> by now.
>
> I would proceed as follows:
>
> 1. Keep that machine off the internet till it is reinstalled
> 2. Fresh reinstall using boot media that you have downloaded and written
> elsewhere, plus a portage tree. Don't worry about distfiles - a fresh portage
> tree won't use existing copies on that machine if the hashes don't match. So
> you can re-use them. If you boot off new install media it is safe to download
> new distfiles using it.
> 3. Keep your old partitions around if you want to do forensics, you can mount
> them somewhere when a reinstall is done and peruse them at your leisure.
> However, doing that is often a waste of time unless you still have logs. You
> can use a scanner like nessus to look things over.
> 4. And it goes without saying that you should change all passwords and keys
> used on that trojaned machine.

Hi Alan, thanks for the advice.

I just remembered that my DD-WRT router stats page had an anomaly, on
31st of July it showed I had over 700 terabytes of traffic, which is
impossible. Coincidentally, my cable modem stopped working on the same
day, so I wrote it off as a bug or a result of the broken modem. I
replaced the modem and everything seemed to work normally after that.

At this point my mind is running wild thinking of all of the
possibilities. Could the router have been infected? The modem? It'll
still be another 5 or 6 hours before I'm able to lay my hands on the
machine. I'm imagining every doomsday scenario. :)

My hope is that it was "only" a botnet or ssh-scanner or something,
and not sniffer or keylogger or anything nefarious. I fear I may never
truly be able to know, though.

Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Alan McKinnon]

On Monday 09 August 2010 18:25:56 Paul Hartman wrote:
> Hi, today when working remotely I ran nethogs and noticed suspicious
> network traffic coming from my home gentoo box. It was very low
> traffic (less than 1KB/sec bandwidth usage) but according to nethogs
> it was between a root user process and various suspicious-looking
> ports on outside hosts in other countries that I have no business
> with. netstat didn't show anything, however, but when I ran chkrootkit
> told me that netstat was INFECTED. I immediately issued "shutdown -h
> now" and now I won't be able to take a further look at it until I get
> home and have physical access to the box. System uptime was a few
> months. It was last updated for installation of a 2.6.33 kernel
> (2.6.35 is out now).
> 
> I have 3 goals now:
> 
> 1) Figure out what is running on my box and how long it has been there.
> 2) Find out how it got there.
> 3) Sanitizing, or most likely rebuilding the system from scratch.

Here's the bad news:

An intruder probably gained access through a script kiddie script, which has 
likely already removed all the logs. Or they have possibly been rotated away 
by now.

I would proceed as follows:

1. Keep that machine off the internet till it is reinstalled
2. Fresh reinstall using boot media that you have downloaded and written 
elsewhere, plus a portage tree. Don't worry about distfiles - a fresh portage 
tree won't use existing copies on that machine if the hashes don't match. So 
you can re-use them. If you boot off new install media it is safe to download 
new distfiles using it.
3. Keep your old partitions around if you want to do forensics, you can mount 
them somewhere when a reinstall is done and peruse them at your leisure. 
However, doing that is often a waste of time unless you still have logs. You 
can use a scanner like nessus to look things over.
4. And it goes without saying that you should change all passwords and keys 
used on that trojaned machine.




> I won't feel comfortable about doing item 3 until I learn the cause of
> 1 and 2. Since this is a home PC, it's not mission-critical and I have
> other computers so I can afford to leave it offline while I
> investigate this security breach, but at the same time it's worrisome
> because I do banking etc from this machine. I'll obviously have to
> check the status of any other computer on the same network.
> 
> My user account has sudo-without-password rights to any command. In
> hindsight this risk may not be worth the extra convenience... A rogue
> "sudo install-bad-stuff" anywhere over time could have done me in.
> 
> Alternatively I was running vulnerable/compromised software. My box
> has sshd running, root login in ssh is not allowed, and pubkey only
> logins (no passwords). It is behind a wireless router but port 22 is
> open and pointing to this box, and a few others needed by other
> applications. So I will check out which keys exist on the compromised
> machine and make sure I recognize them all. I'll also need to check
> the status of any other computer my key is stored on (a mix of linux &
> windows, and my mobile phone). Sigh...
> 
> I am using ~amd64 and I update deep world about 3 times a week normally.
> 
> The computer is only a few months old, but it was created by cloning a
> ~2-years-old computer.  I did emerge -e world as part of the upgrade
> process.
> 
> If anyone has advice on what I should look at forensically to
> determine the cause of this, it is appreciated. I'll first dig into
> the logs, bash history etc. and really hope that this very happened
> recently.
> 
> Thanks for any tips and wish me good luck. :)

-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Rooted/compromised Gentoo, seeking advice

[Paul Hartman]

Hi, today when working remotely I ran nethogs and noticed suspicious
network traffic coming from my home gentoo box. It was very low
traffic (less than 1KB/sec bandwidth usage) but according to nethogs
it was between a root user process and various suspicious-looking
ports on outside hosts in other countries that I have no business
with. netstat didn't show anything, however, but when I ran chkrootkit
told me that netstat was INFECTED. I immediately issued "shutdown -h
now" and now I won't be able to take a further look at it until I get
home and have physical access to the box. System uptime was a few
months. It was last updated for installation of a 2.6.33 kernel
(2.6.35 is out now).

I have 3 goals now:

1) Figure out what is running on my box and how long it has been there.
2) Find out how it got there.
3) Sanitizing, or most likely rebuilding the system from scratch.

I won't feel comfortable about doing item 3 until I learn the cause of
1 and 2. Since this is a home PC, it's not mission-critical and I have
other computers so I can afford to leave it offline while I
investigate this security breach, but at the same time it's worrisome
because I do banking etc from this machine. I'll obviously have to
check the status of any other computer on the same network.

My user account has sudo-without-password rights to any command. In
hindsight this risk may not be worth the extra convenience... A rogue
"sudo install-bad-stuff" anywhere over time could have done me in.

Alternatively I was running vulnerable/compromised software. My box
has sshd running, root login in ssh is not allowed, and pubkey only
logins (no passwords). It is behind a wireless router but port 22 is
open and pointing to this box, and a few others needed by other
applications. So I will check out which keys exist on the compromised
machine and make sure I recognize them all. I'll also need to check
the status of any other computer my key is stored on (a mix of linux &
windows, and my mobile phone). Sigh...

I am using ~amd64 and I update deep world about 3 times a week normally.

The computer is only a few months old, but it was created by cloning a
~2-years-old computer.  I did emerge -e world as part of the upgrade
process.

If anyone has advice on what I should look at forensically to
determine the cause of this, it is appreciated. I'll first dig into
the logs, bash history etc. and really hope that this very happened
recently.

Thanks for any tips and wish me good luck. :)

[gentoo-user] bluetooth device bd address is 11:11:11:11:11:11

[Xi Shen]

hi,

i have a usb bluetooth device, after i plug it into the usb slot and
ran hciconfig, it shows the bd address is 11:11:11:11:11:11. is it
correct? or maybe the driver is not loaded correctly?


-- 
Best Regards,
Xi Shen (David)

http://twitter.com/davidshen84/