LinuxQuestions.org - Crack attempt trying to grab the passwd file

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - Crack attempt trying to grab the passwd file (https://www.linuxquestions.org/questions/linux-security-4/crack-attempt-trying-to-grab-the-passwd-file-4175411285/)

Crack attempt trying to grab the passwd file

Hello --

One of our servers was subjected to a crack attempt that tried to grab the /etc/passwd file. The file does not appear to have been touched due to the timestamp on the file not being of a recent date. However, just to make sure, I wanted to know if there are other tests that can be done to verify this.

One thought that I had was the following: The server is regularly backed up, and I could do a restore of an older version of the passwd file to a temporary directory. Once there, the diff command could be used to compare the two files.

You could compare but with the timestamps more than likely nothing was modified. However, the timestamps won't tell you if it was read successfully by the request which would give the cracker the list of user accounts set up on the server. The /etc/passwd file is world readable by default so it could be read by any other user that attempted to get it. Wikipedia has some info on this type of attack: http://en.wikipedia.org/wiki/Directory_traversal_attack

You can do some searching on how to prevent this but its usually only prevented with input sanitation done on the web server level.

Quote:

Originally Posted by kaplan71 (Post 4702471)

One of our servers was subjected to a crack attempt that tried to grab the /etc/passwd file.

How exactly did you determine this? Wasn't it only one line in a long line of what appears to be web stack application probes?
Being as verbose as possible would be appreciated.

Hello --

I was informed of the attack via e-mail from our Information Security team. The text of the e-mail is shown below:

Quote:

Open Time: 06/07/12 20:32:32
Summary: Host_Query:Raw Event:Host Query eventId=6823616802413 vendor=Cisco eventType=evIdsAlert hostId=eips1 appName=sensorApp appInstanceId=13530 tmTime=1339119106675 severity=3 interfaceGroup=vs0 Interface=PortChannel0/0 Protocol=tcp riskRatingValue=75 sigId=32
Priority: High
Device Name: <name> (Primary)
Site ID: <site location>

The incident has been classified by our support engineers:

Alarm Source: Malicious
Sub Category: Exploits
Actions: No Action

Classification Details:
Malicious packet triggered on Sig-ID 3201/1.

Alarm triggered on Unix Password File Access Attempt traffic from the external host at <ip address> to the external host at <ip address>.

These alarms triggers when any cgi-bin script attempts to retrieve password files on various operating systems. Such as the /etc/passwd. This may indicate an attempt to illegally access system resources, in particular the /etc/passwd file. This may be the prelude to a more serious attack. No valid reason to access these files via this mechanism exists. Hosts that attempt to access the these files, especially from outside your network, should be shunned. The internal host should also be checked for possible compromise.

I am going through the system and web server log files to determine if a successful connection was made, and the file in question was accessed from the remote system.

Changing passwords now and often may help.

Not sure how much help a modern linux disto's file is vulnerable to a common hacker even.

You have the event date and time. Look at your Apache error and access logs for a query that contains passwd and, or shadow, probably with a bunch of ../../ in it. Normally, a user should not be able to browse outside of the document path, but it is prudent to see if access to this file were gained.

//Also don't forget the recent CVE-2012-1823.