Recently my vulnerability assessment team was asked to assist in
determining the root cause of a compromise of a customer's RaQ 4 that was
alleged to be totally patched. Upon investigation, a summary of which appears
below, it was determined the appliance had actually been compromised prior to
being properly patched and had not been thoroughly eradicated after detection
of the compromise thus negating any subsequent patching effort.
I
would like to share the results of this effort as they provide an excellent
learning vehicle. The key point to come away from concerning this effort is
that adherence to a proper incident response methodology is critical to
successful recovery from these types of events. However, failure to
effectively/adequately perform any step in that process, in this case
inadequate eradication, will most certainly result in a failed recovery
effort, no matter how well written the incident response plan is.
_____________________________________________________________________________________________________________________________________________________
Forensic
evidence indicates that the break in occurred between January 15 at 03:02 and
11:04 server local time. This is evidenced by the httpd error log
entries below and the file time stamps on the files located in /var/tmp on the
compromised host. The initial entry in the /var/log/httpd/error log file
is most likely a scanner programed to locate vulnerable
machines.
[Wed Jan 15 03:02:37 2003] [error] mod_ssl: SSL handshake
failed (server www.xxxxxxx.net:443, client
xxx.xxx.xx.xx) (OpenSSL library error follows)
[Wed Jan 15 03:02:37 2003]
[error] OpenSSL: error:1406908F:SSL routines:GET_CLIENT_FINISHED:connection id
is different
would you expect to see this in a non hacked box a
quick cat and grep of http/error shows some SSL handshake fails with OpenSSL
library error
[Wed
Jan 22 22:23:47 2003] [error] mod_ssl: SSL handshake failed (server www.xxxxxx.com:443, client 62.246.118.5)
(OpenSSL library error follows)
also
in /var/tmp we have some files
-rw------- 1 httpd
root 354 Jan 23 16:06
sess_0f2d7d53b4811a35dddb24775e36709c
which when expanded look like this - is this
normal?
[root tmp]# cat sess_0f2d7d53b4811a35dddb24775e36709c
attachment_common_types|a:7:{s:9:"image/gif";b:1;s:15:"image/x-xbitmap";b:1;s:10:"image/jpeg";b:1;s:11:"image/pjpeg";b:1;s:24:"application/vnd.ms-excel";b:1;s:18:"application/msword";b:1;s:3:"*/*";b:1;}attachment_common_types_parsed|a:1:{s:102:"image/gif,
image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel,
application/msword, */*";b:1;}[root tmp]#
also
is this the right command for finding if a file has been altered in the last 8
days?
find / -atime +8 -print
a
quick look at man shows this as accessed not modified - hence a bucket load of
answers that made me rush for the john
-atime
n
File was last accessed n*24 hours ago.
We
keep our RaQs patched up to date - as best we can when the patches are
announced or someone else on the list notices but we have had some oddities in
the last couple of days that worry me.
any
views or ideas welcome
Regards
Gavin
ps I
suspect this was meant for internal only but to see this sort of info makes a
welcome change and Sun should do this more often we all have cobalts after all
to be honest even if it meant a tighter list with a check on serial number or
something to be able to see this sort of in depth info can only make
everyone's impression of Sun
better.