LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Odd hacking attempt.... (https://www.linuxquestions.org/questions/linux-security-4/odd-hacking-attempt-770341/)

LordBoreal51 11-19-2009 08:33 PM

Odd hacking attempt....
 
I'm a relative newbie to the world of Linux, I've dabbled in Ubuntu but never have been a big command line person, so that world is unfamiliar. Anyway, I run an SSH server in a Damn Small Linux VM, and earlier today I was getting strange connection errors when connecting with putty. When I got home I checked the DSL server, and noticed that a Bash terminal I had left open now had history of ten or so commands I never entered. Stuff like "adduser" and attempts at accessing passwords and elevating to root. It doesn't look like anything worked, but I have a few questions:

1. How would these commands appear in the terminal (other than physical access)?

2. Is there any way to see a log of connections to see whether they attempted to connect with SSH or something else?


Thanks for the help

i92guboj 11-19-2009 10:03 PM

You will have to check the ssh logs. Where they live, will depend on the system logger you use and/or the ssh configuration, but you can start looking in /var/log/ssh*. However, if the attacker truly scaled to root privileges, I doubt he left without "retouching" or erasing the log files to hide the attack.

The commands do not appear in the terminal (whatever you understand by "terminal"). Ssh listens at a given port for remote connections, as long as sshd and the firewall are configured to do so. If someone connects remotely s/he will get a shell session, where s/he can issue commands just like you would do on a local terminal (i.e. an xterm in your desktop). This remote session has no existence within your desktop session or something like that (that mostly happens in movies).

LordBoreal51 11-19-2009 10:14 PM

Okay. That confirms what I thought. An open Bash Terminal would not reflect any SSH activity. So the only logical explanation would be that this person VNCed in through VMWare (I have Remote Access enabled). Just for clarification, I am referring the xterm instance of bash when I say "terminal." This is where these odd commands were seen and physical access to the machine is 99.99% unlikely.

Along that note, on the terminal session, these commands start after the line "Linux box 2.4.31 #6 SMP Fri Oct 21 15:15:54 EDT 2005 i686 unknown". Above this line, I recognize the commands I had entered from earlier. But below it starts this apparent hacking attempt. So what does that mean? Judging from the timestamp is it some sort of session initialization? And does it provide any information about what method the hacker used to gain access? (since SSH was already ruled out for this particular attempt)

Thanks.

Hangdog42 11-20-2009 08:01 AM

Quote:

So the only logical explanation would be that this person VNCed in through VMWare (I have Remote Access enabled).
Can we get a little clarification here on a few things?

- VNC usually establishes its own desktop, separate from the one visible on the screen. Have you done something so that VNC is sharing the visible desktop?

-Is the VNC port actually visible to the outside world? And how big is that outside world? Your LAN? The entire internet? A description of how you have your network set up, including the VM your running, would be very helpful.



You probably also need to spend some quality time looking at your log files and see if you can spot anything unusual. Since you know the time frame this incident occurred, that is where you should be looking.

Jim Bengtson 11-20-2009 08:08 AM

I've heard that you should not have a GUI on a server because it's a security risk. But the only way for someone to enter commands that appear in your terminal window is for them to hijack your GUI. This thread discusses just such an attack...

http://www.hermann-uwe.de/blog/how-t...tion-via-ssh-x

tredegar 11-20-2009 11:24 AM

Quote:

Anyway, I run an SSH server in a Damn Small Linux VM, and earlier today I was getting strange connection errors when connecting with putty. When I got home I checked the DSL server....
OK.

So your VNC server is accessible from the outside world [ and probably has a weak password, and was probably running on the default port ]. This makes it easy to brute-force attack.

Quote:

I was getting strange connection errors when connecting with putty
Presumably because someone else was using your VNC server screen, therefore YOU couldn't connect to it at the same time.

Quote:

1. How would these commands appear in the terminal (other than physical access)?
My guess is that they came in through your VNC connection, and guessed the VNC password, so landing in your GUI. You should confirm this.

My suggestions:
0] Don't reboot anything until you have completed your forensics.
1] Immediately close the VNC ports on your firewall (ie stop forwarding them to your LAN). Do not reopen them until you are sure you have identified and solved the security hole.
2] Confirm that the above is indeed how they got in (check the logs).
3] Consider: Has anything else on your LAN been compromised?
4] Check this link
5] Read up on running vnc over ssh with key-based (NOT password) authentication. It's easy and secure.

repo 11-20-2009 11:37 AM

Could it be someone has physical access to the box?

tredegar 11-20-2009 12:02 PM

Quote:

Could it be someone has physical access to the box?
It's "at home".

But the possibilities are multiple, until we have more information from the OP.

I start a VNC server on my server:1 when it boots. It sits there idly until I want to connect to / disconnect from / reconnect to it from elsewhere on my LAN. When I reconnect, my previous windows are open and ready for me to use. It's handy, though I rarely use it, it is there when I want it.

But
:

It is inaccessible from the WWW.
Even on my LAN I use VNC tunnelled through key-based ssh authentication.

This is just so I can remember how to, and it is "good practice".
My VNC password is trivial, the (good) security comes from ssh and key-based authentication.

Thaidog 11-20-2009 12:34 PM

Quote:

Originally Posted by Hangdog42 (Post 3763883)
- VNC usually establishes its own desktop, separate from the one visible on the screen.

Not in my experience... it usually connects to the gui that is open. Terminal Services on Windows however makes it's own desktop. Perhaps this has changed or its an new debian/ubuntu thing?

mrclisdue 11-20-2009 07:47 PM

I'm with Hangdog42 on this one. Any Linux VNC that I have experience with establishes its own desktop session which is separate from any session currently running locally on the VNC server. This is why x11vnc exists, which enables the "current" desktop to be displayed remotely.

This is not true for MS Windows, of course, and we need not get into the reasons.

cheers,

Thaidog 11-21-2009 04:14 AM

Quote:

Originally Posted by mrclisdue (Post 3764516)
I'm with Hangdog42 on this one. Any Linux VNC that I have experience with establishes its own desktop session which is separate from any session currently running locally on the VNC server. This is why x11vnc exists, which enables the "current" desktop to be displayed remotely.

This is not true for MS Windows, of course, and we need not get into the reasons.

cheers,

Yes but I think he is not on Linux for the base system. He has DSL running in a vm and it sounds like he's got the vm running on a Windows host.

Hangdog42 11-21-2009 06:48 AM

Quote:

Originally Posted by Thaidog (Post 3764762)
Yes but I think he is not on Linux for the base system. He has DSL running in a vm and it sounds like he's got the vm running on a Windows host.

Yes, but the problem appears to be with DSL, not Windows. In this case I think it is safe to treat DSL as if it were a standalone machine. However, until the OP returns with more information, the only thing we can do is guess and that doesn't get anybody anywhere.

LordBoreal51 11-21-2009 12:53 PM

So some clarification about VNC:

-I am using the VNC server present in VMware, which *does* replicate the original desktop.

-However, I do *not* have any port forwarding rules configured for my VNC port through my router, so (as far as I know) it's only directly accessible through my home LAN.

unixfool 11-21-2009 10:18 PM

I'd be nice if the OP used the handy ole' Intruder Detection Checklist (CERT): http://web.archive.org/web/200801092...checklist.html.

Would also be nice if he posted a bit of those log files (SSH specifically).

Hangdog42 11-22-2009 07:24 AM

Quote:

-I am using the VNC server present in VMware, which *does* replicate the original desktop.
I didn't even know this existed until now (there is a decent description here if you haven't heard of it either). When you enabled this, did you also specify that a password was required? From what I can tell, this VNC service doesn't require one unless you specify it.

Quote:

-However, I do *not* have any port forwarding rules configured for my VNC port through my router, so (as far as I know) it's only directly accessible through my home LAN
Well, this suggests that either someone you know and have given access to your LAN did this or another machine on your LAN has been compromised (or perhaps the LAN itself if you have wireless) and you no longer have control of your network. If you want to get to the bottom of this, you need to start posting some of the evidence we've been asking for. We're glad to help, but we need some evidence and logs to make any real progress in understanding this.


To be honest, I'm shocked that VMWare included such a huge security hole in their product. As far as I can tell, this is basic unsecure VNC and at best can have only minimal password protection.


All times are GMT -5. The time now is 09:02 PM.