LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 02-07-2004, 07:06 PM   #1
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Rep: Reputation: 30
**HACKED** Snort log posted


Believe it or not, I was online for 4 hours downloading info to load on my brand new Samba server. While I was doing so, I was being hacked OVER A DIAL UP CONNECTION! At the time, I was sharing my dial connection via XP Pro (only because my modem isn't linux compatible). Proof that Windows should never directly touch the Internet. Yes I was running this apparently useless XP firewall and I keep my updates current. Once the attacker took over the XP machine, they started in on my new Samba server. The XP machine is 192.168.0.1 and the Samba server is 192.168.0.100. Here is the snort log:


[1:469:1] ICMP PING NMAP [Classification: Attempted Information Leak] [Priority: 2]: {ICMP} 192.168.0.100 -> 192.168.0.1
[1:535:4] NETBIOS SMB CD... [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.0.1:3156 -> 192.168.0.100:139
[1:535:4] NETBIOS SMB CD... [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:535:4] NETBIOS SMB CD... [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:535:4] NETBIOS SMB CD... [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:681:4] MS-SQL/SMB xp_cmdshell program execution [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:681:4] MS-SQL/SMB xp_cmdshell program execution [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1295:7] NETBIOS nimda RICHED20.DLL [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:677:5] MS-SQL/SMB sp_password password change [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:703:5] MS-SQL/SMB xp_setsqlsecurity possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:681:4] MS-SQL/SMB xp_cmdshell program execution [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:678:5] MS-SQL/SMB sp_delete_alert log file deletion [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:535:4] NETBIOS SMB CD... [Classification: Attempted Information Leak] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:703:5] MS-SQL/SMB xp_setsqlsecurity possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:695:5] MS-SQL/SMB xp_sprintf possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:703:5] MS-SQL/SMB xp_setsqlsecurity possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:702:5] MS-SQL/SMB xp_displayparamstmt possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:698:5] MS-SQL/SMB xp_proxiedmetadata possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:677:5] MS-SQL/SMB sp_password password change [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:469:1] ICMP PING NMAP [Classification: Attempted Information Leak] [Priority: 2]: {ICMP} 192.168.0.100 -> 192.168.0.1
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1295:7] NETBIOS nimda RICHED20.DLL [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:677:5] MS-SQL/SMB sp_password password change [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:678:5] MS-SQL/SMB sp_delete_alert log file deletion [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:681:4] MS-SQL/SMB xp_cmdshell program execution [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:689:4] MS-SQL/SMB xp_reg* registry access [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1386:4] MS-SQL/SMB raiserror possible buffer overflow [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3171 -> 192.168.0.100:139
[1:1882:4] ATTACK-RESPONSES id check returned userid [Classification: Potentially Bad Traffic] [Priority: 2]: {TCP} 192.168.0.1:3735 -> 192.168.0.100:10000

I've since updated to DSL and a true firewall. Enjoy and comments are welcome. In the meantime I have an XP machine rebuild. It will be fun calling Microsoft and telling them I need a new registration number because I had to reload their OS after being hacked!
 
Old 02-07-2004, 07:20 PM   #2
GarrathE
LQ Newbie
 
Registered: Aug 2003
Distribution: Red Hat Fedora
Posts: 9

Rep: Reputation: 0
Thumbs down

A Linux user believing Microsoft's claim about XP Firewall? :-O But seriously, don't use it. Get ZoneAlarm and turn the built in cr*p off.
 
Old 02-07-2004, 07:31 PM   #3
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
Looks like they may have exploited the MS-SQL vuln that SQL Slammer took advantage of... Were you even keeping your XP box up to date with security fixes? If not, that's hardly Microsoft's fault. The patches have been out for a looooooong time.
 
Old 02-07-2004, 08:30 PM   #4
dekket
Member
 
Registered: Oct 2003
Location: sweden
Distribution: debian
Posts: 47

Rep: Reputation: 15
Quote:
Originally posted by chort
Looks like they may have exploited the MS-SQL vuln that SQL Slammer took advantage of... Were you even keeping your XP box up to date with security fixes? If not, that's hardly Microsoft's fault. The patches have been out for a looooooong time.
The question already seems answered at the top of this thread...
 
Old 02-07-2004, 08:34 PM   #5
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Original Poster
Rep: Reputation: 30
Re: **HACKED** Snort log posted

Quote:
Originally posted by ghight
... and I keep my updates current.
Yes, even with my dial up connection, I was keeping up to date with the updates, but apparently, keeping my dial up online long enough to download the new update is in itself a security issue. The very definition of "catch 22".

Last edited by ghight; 02-07-2004 at 08:36 PM.
 
Old 02-07-2004, 09:17 PM   #6
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
I missed the part about the updates, still it's very strange. It looks pretty obvious that it was a SQL exploit. Did you have a SQL server on the XP box? Perhaps some of the table permissions were not set correctly or something, and the attacker was able to use a SQL command injection or some similar method.

Any way, looks like a good reason to have Snort running and up to date. Even if you think everything is secure, you still may be successfully attacked.
 
Old 02-07-2004, 09:54 PM   #7
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Original Poster
Rep: Reputation: 30
I use a LAMP server system on my XP machine to test my Dreamweaver pages, but that would not have been the problem, otherwise, nope, no IIS or MS-SQL or anything. I am a network administrator by profession, so I keep a pretty tight ship, at least what I am aware of. I made one stupid mistake and it bit me. The part the gets me is that if the attacker didn't go after my linux server with the snort detection, I would have never known. There is absolutely NO indication that my computer was hacked. I even keep a virus scanner that would have noticed a script such as this, yet it missed it too.

There was nothing that the attacker could have gotten off of any of my computers that was worth a damn, so I'm not too worried. I will reload both of these computers however, just to be safe.
 
Old 02-07-2004, 10:09 PM   #8
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 69
If you look at the timestamps of the snort entries, are they spaced relatively close together indicating an automated tool/worm or are they farther apart and relatively un-uniform indicating someone manually trying exploits? Interesting to trace through each sequence of attacks.
 
Old 02-07-2004, 11:47 PM   #9
witeshark
Member
 
Registered: Jan 2004
Location: Miami FL
Distribution: Mac OS X 10.4.11 Ubuntu 12.04 LTS
Posts: 429

Rep: Reputation: 30
Quote:
Originally posted by dekket
The question already seems answered at the top of this thread...
I think this has an angle that is faster then analyzing all the logs. the doz native firewall lacks outgoing packet scans totally I agree that quiting the XP firewall and downloading Zonelabs may actually help! this is the firewall that surprised me with absolute success in my last doz days It's worth a look! http://www.zonelabs.com I was impressed!

Last edited by witeshark; 02-08-2004 at 12:11 AM.
 
Old 02-07-2004, 11:52 PM   #10
witeshark
Member
 
Registered: Jan 2004
Location: Miami FL
Distribution: Mac OS X 10.4.11 Ubuntu 12.04 LTS
Posts: 429

Rep: Reputation: 30
Lightbulb

Quote:
Originally posted by Capt_Caveman
If you look at the timestamps of the snort entries, are they spaced relatively close together indicating an automated tool/worm or are they farther apart and relatively un-uniform indicating someone manually trying exploits? Interesting to trace through each sequence of attacks.
Like I have suggested before timing is crucial nice Capt_Caveman I hope my previous helps

Last edited by witeshark; 02-07-2004 at 11:57 PM.
 
Old 02-08-2004, 09:23 AM   #11
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Original Poster
Rep: Reputation: 30
Obviously there was a lot edited out of the log so I could get a resonable size post, but everything you see was over a 2 and a half hour timeframe. There are furies of activity that are within 40 seconds of each other, then it stopped for a few minutes to an hour and then more short furies. Looks like scripts to me being run manually.
 
Old 02-08-2004, 09:29 AM   #12
snacky
Member
 
Registered: Feb 2004
Distribution: Debian
Posts: 286

Rep: Reputation: 30
Shut down the SQL server and get online to grab the windows updates. I agree with the poster who says this is all your fault for not keeping up to date. Same thing happens to Linux users who run too many services and don't watch the security updates for them.
 
Old 02-08-2004, 09:38 AM   #13
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Original Poster
Rep: Reputation: 30
Man are you even bothering to read the posts?? I always keep XP up to date and I have NO MS-SQL server running. Geez, if you are going to post some half-assed comment atleast make sure it hasn't already been answered, AND TWICE MIGHT I ADD!
 
Old 02-08-2004, 02:58 PM   #14
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
BTW, the System Monitor application in Windows actually has an embedded SQL server to store the stats in. Even if you're not explicitly running MS SQL, it will be there (let me see if I can find the exact name of the app). A lot of companies were very surprised when their Windows boxen got hosed by the SQL Slammer worm, even though they didn't think they were running SQL databases on those boxen.

Edit: Well I couldn't find the specific information I was looking for, but it does look like "System Monitor" (actual name) uses an embedded SQL Server, so that would be vulnerable. Also interesting is that MS Visual Studios and MS Office Development Edition also contain SQL servers.

More info can be found here: http://www.microsoft.com/technet/tre...letin MS02-039

Last edited by chort; 02-08-2004 at 03:08 PM.
 
Old 02-09-2004, 08:11 AM   #15
ghight
Member
 
Registered: Jan 2003
Location: Indiana
Distribution: Centos, RedHat Enterprise, Slackware
Posts: 524

Original Poster
Rep: Reputation: 30
That must have been the open door! I was curious what exactly could have been the culprit.

Lesson learned, although, there is apparently, not much you can do about that. What are the odds on convincing MS to run System Monitor on MySQL?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
log system hacked? mikechao Linux - Security 3 09-14-2005 10:46 PM
Snort don't want log to mysql lcat Slackware 1 03-07-2005 07:20 AM
I can't get snort to log anything abefroman Linux - Security 2 09-07-2004 09:09 AM
SNort&log JuBeC Linux - Security 1 05-04-2004 09:33 PM
Snort is not log chamkila Linux - Security 19 06-18-2003 02:30 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:43 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration