Welcome to the MacNN Forums.

Xeo · May 22, 2005, 06:20 AM

Part of this post is story, the other is question.

First the question, is there a log of when people SSH in to my computer? system.log doesn't seem to show those accesses. Nothing else in /var/log looks like it'd be it.

But here's the story. I have an iBook as my main computer. I decided to change my short username. Doing it manually was a stupid idea, and I ended up making it so I wasn't an admin anymore and I couldn't sudo. It was a mess. Luckily I had another user on my system, a guest account, and it was an admin user. But it couldn't sudo either. So I used that account to create a 3rd "test" account. Username test, password test. I used that to run an app I found which would change the short username of my other user. I also took the opportunity to use a new, more secure password on my account. Go security.

At this point, I turn on SSH and AppleShare for the first time in like 6 months. I don't need it much, but I just made my password secure and every now and then I do. Well, I've been working on stuff all night since then, and out of no where, Little Snitch asks me if ftp can connect to some random server. I do lookups on it and decide I didn't start it so I denied it. A few min later, another ftp attempt to another server. Then a curl attempt, another curl attempt. I drop into Terminal and type "who" only to discover that my "test" account was logged in from some aol server!

My first reaction was to delete the test user and restart to make sure anything they started was gone. Then I checked the logs. They had never made user of sudo, thankfully. But other than that I don't know what they did. They could have easily made my life hell right now.

So anyway, Little Snitch saved me. I wouldn't have even known it was going on if it hadn't told me so. All because I created a user a few hours ago, turned on a service I didn't really need, and someone with my IP decided to try and access it with test/test. Bizarre that it happened so quickly after I became vulnerable.

So what's the lesson? Don't EVER create a user on your system with a lame password. It apparently doesn't take long for someone to make use of it.

I'd really like to find out what IP that was from, though. I had it up for a bit when I typed "who" but I didn't write it down at the time. I'd report them to AOL if I could find it.

Phew, that was kinda long. Sorry.

philm · May 22, 2005, 07:21 AM

Great story with a great lesson. I for one have learned something there. Cheers.

wadesworld · May 22, 2005, 10:52 AM

Login information is stored in the wtmp file. It can be read with the "last" program.

You should watch your system very carefully. There are a couple of rootkits available for OS X, and if he installed one of those, he would still have access.

The chances aren't that high though, so I'd probably just change all passwords on the system and watch it closely.

Wade

legacyb4 · May 22, 2005, 10:59 AM

If you had used test/test, then it might be a good chance that it was an automated attack as well...

Originally Posted by Xeo

So what's the lesson? Don't EVER create a user on your system with a lame password. It apparently doesn't take long for someone to make use of it.

Buckaroo · May 22, 2005, 11:14 AM

Interesting. I'll have to check my wtmp file.

Buckaroo · May 22, 2005, 11:56 AM

Where is this wtmp file? I did a search and nothing came up.

Appleman · May 22, 2005, 12:04 PM

Originally Posted by Buckaroo

Where is this wtmp file? I did a search and nothing came up.

I (Spotlight actually) found this in smb.conf.5.html

----------------------------------
wtmp directory (G)
This parameter is only available if Samba has been configured and compiled with the option --with-utmp. It specifies a directory pathname that is used to store the wtmp or wtmpx files (depending on the UNIX system) that record user connections to a Samba server. The difference with the utmp directory is the fact that user info is kept after a user has logged out.

By default this is not set, meaning the system will use whatever utmp file the native system is set to use (usually /var/run/wtmp on Linux).

Default:

wtmp directory =

Example:

wtmp directory = /var/log/wtmp

Related are:

utmp
----------------------------------

Have not really a clue what it means though

wadesworld · May 22, 2005, 12:09 PM

it's in /var/log/wtmp

However, if memory serves, it's a binary file. Use the "last" program to see the contents.

Wade

Chuckit · May 22, 2005, 12:10 PM

As he said, you don't need to know where it is to read it. Just type "last".

Xeo · May 22, 2005, 01:48 PM

Excellent, I have the IP. There are actually 3 separate connections within the span of 2 minutes, all using test. Something tells me none of them are the originating IP and the bot behind them had already hijacked their server.

But yeah, it was definitely an automated attack. I looked at secure.log and there were attempts to log in as test, user, root, and admin. I think that's all. So basically, common usernames. I assume this means my computer is hit daily if not more with attempts to log in and they've always been unsuccessful. I'd like a way to auto-log these failures, so if anyone knows how to log all accesses coming in to my computer, I'm all ears.

Originally Posted by wadesworld

Login information is stored in the wtmp file. It can be read with the "last" program.

You should watch your system very carefully. There are a couple of rootkits available for OS X, and if he installed one of those, he would still have access.

The chances aren't that high though, so I'd probably just change all passwords on the system and watch it closely.

Wade

Thanks a bunch for the "last" command. That's one I hadn't heard of (which is rare for me, these days). Always something new.

But I'm not too worried about them having installed anything. They didn't sudo and I don't have root enabled, so I don't think they would have had permissions to install anything otherwise. (There's nothing in StartupItems and I think that's the only place something could have been placed while unprivileged.

Basically, from the logs I can see that they only had access for a total of 7 minutes. While that's plenty to do whatever they want, especially with the ability to go root, over those 7 minutes nothing else is in the logs to make me worried.

Still, I find it was an interesting exercise and learning experience for me.

Recto Bold · May 23, 2005, 06:18 AM

Wow - Scary stuff. I, for one, never regretted paying for Little Snitch - It's a great app. It'd be great to have Apple build this fucntionality into the OS, IMHO. Security these days seems so centred around who is trying get IN, when on occasion it's really nice to know what is trying to get OUT too!

Anyway, thanks for the story. I've just hurriedly deleted my "test" account too (he said with a red face). Doh!!

Finrock · May 23, 2005, 07:26 AM

The exact same thing happened to me last fall, and Little Snitch saved me. I was slightly paranoid, but since my test account wasn't an admin account I was fairly sure that no data was compromised.

It was interesting to see the logs, I think it was console.log or system.log, where it had tried to ssh into the computer using a bunch of different usernames, many of which were simple first names (ie. dave, jim, etc.) to the usual (admin, test, root, etc.).

Thanks for posting the story, I hope many people will read it.

Simon · May 23, 2005, 07:31 AM

This is why I had MkConsole always show my system.log and console.log files on top of my desktop background. When somebody was trying to hack into my machine, I saw immediately where he was coming from and with which user name he was trying to gain access.

Unfortunately, with Tiger this no longer works, since sshd log entries are no longer written to these files.

Appleman · May 23, 2005, 07:33 AM

Without understanding much of all this, I am now wondering if this can happen to anyone 24/7 connected to internet. I only have one user, myself, with a password. Root is not enabled. Filevault is not enabled.
In the Advanced Tab of Sharing->Firewall, I can see several "Stealth Mode" attempts. What does this mean for security? Should I use "Block UDP Blocking" as well?
Why is this not standard turned on?
Thanks.

jamil5454 · May 23, 2005, 09:30 AM

It's really easy to go out and buy a cheap $30 router/hardware firewall to put yourself behind. With my Linksys WRT54G, all attacks are blocked at the router level. In fact, the router blocks all ping requests so bots like those don't even know I'm up.

Xeo, see if you can't find a way to block ping requests from the WAN side. I'll bet a million dollars that the bot first pinged your IP, discovered it was alive, then proceeded to try a list of logins. While the bot itself didn't do anything, I'm sure the bot logged its successful login to a list of successful logins for some cracker to attack later at his convenience. Unless your IP changes, the cracker will probably try to login with test/test and use your computer as a wares server or proxy.

Chuckit · May 23, 2005, 09:55 AM

Originally Posted by Appleman

Without understanding much of all this, I am now wondering if this can happen to anyone 24/7 connected to internet.

Only if you have remote login enabled. Xeo enabled remote login over SSH, and one of his accounts unfortunately had an extremely common user/pass combination, so basically any bot had access to his computer if it wanted to try. As long as you don't have a port open for remote login, you're in a different situation.

The best advice is the same as always: Use good passwords, don't open any ports you don't have to, and use a hardware firewall for the best security.

Appleman · May 23, 2005, 09:57 AM

Originally Posted by Chuckit

Only if you have remote login enabled.

Me no have.

:XI: · May 23, 2005, 10:29 AM

Originally Posted by Chuckit

Only if you have remote login enabled. Xeo enabled remote login over SSH, and one of his accounts unfortunately had an extremely common user/pass combination, so basically any bot had access to his computer if it wanted to try. As long as you don't have a port open for remote login, you're in a different situation.

The best advice is the same as always: Use good passwords, don't open any ports you don't have to, and use a hardware firewall for the best security.

You could always use public keys with SSH too.