/usr/bin/dbilogstrip Modified

OtagoHarbour · 04-01-2014, 07:04 AM

I intsalled CentOS 6.5 on my system about 5 days ago and LAMP about three days ago. I also changed the name of the computer about 3 days ago. Yesterday, I looked at my Tripwire logs and saw that /usr/bin/dbilogstrip had been modified two days ago. This was confirmed with

Code:

ls -l /usr/bin/dbilogstrip

Does this indicate malware or are there other tests I should do?

Thanks,
OH

unSpawn · 04-01-2014, 07:26 PM

Quote:

Originally Posted by OtagoHarbour

(..) I looked at my Tripwire logs and saw that /usr/bin/dbilogstrip had been modified two days ago. (..) Does this indicate malware or are there other tests I should do?

Not enough nfo:
- what does the TW log actually say?
- what does 'rpm -Vv $(rpm -qf /usr/bin/dbilogstrip --qf="%{name}\n")|grep -v '^\.\{8\}';' return?
- do you run prelink?
- what does 'stat /usr/bin/dbilogstrip' return?
- any other files with similar or close by mtime?
- what (automated?) processes or jobs ran around the mtime?
- user logins around the time?
- system / daemon log entries?

OtagoHarbour · 04-02-2014, 10:12 PM

Thank you for your reply.

Quote:

Originally Posted by unSpawn

Not enough nfo:
- what does the TW log actually say?

Rule Name: User binaries (/usr/bin)
Severity Level: 66
-------------------------------------------------------------------------------
----------------------------------------
Modified Objects: 1
----------------------------------------

Modified object name: /usr/bin/dbilogstrip

Property: Expected Observed
------------- ----------- -----------
Object Type Regular File Regular File
Device Number 2051 2051
Inode Number 286925 286925
Mode -rwxr-xr-x -rwxr-xr-x
Num Links 1 1
UID root (0) root (0)
GID root (0) root (0)
Size 1465 1465
* Modify Time Thu 19 Aug 2010 08:28:07 PM EDT
Sun 30 Mar 2014 07:56:56 PM EDT
Blocks 8 8
CRC32 CzdFNl CzdFNl
MD5 DzanBe3QqtT9R4G9cK2Hgb DzanBe3QqtT9R4G9cK2Hgb

Quote:

Originally Posted by unSpawn

- what does 'rpm -Vv $(rpm -qf /usr/bin/dbilogstrip --qf="%{name}\n")|grep -v '^\.\{8\}';' return?

.......T. /usr/bin/dbilogstrip

Quote:

Originally Posted by unSpawn

- do you run prelink?

Not that I'm aware of. That was the first time I had heard of it.

Quote:

Originally Posted by unSpawn

- what does 'stat /usr/bin/dbilogstrip' return?

File: `/usr/bin/dbilogstrip'
Size: 1465 Blocks: 8 IO Block: 4096 regular file
Device: 803h/2051d Inode: 286925 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2014-04-02 03:36:29.841107654 -0400
Modify: 2014-03-30 19:56:56.165746180 -0400
Change: 2014-03-30 19:56:56.165746180 -0400

Quote:

Originally Posted by unSpawn

- any other files with similar or close by mtime?

These files are sorted by mtime.
/sys/module/xt_state/sections/.gnu.linkonce.this_module
/sys/module/xt_state/sections/.init.text
/sys/module/xt_state/sections/.note.gnu.build-id
/sys/module/xt_state/sections/.rheldata
/sys/module/xt_state/sections/.rodata.str1.4
/sys/module/xt_state/sections/.strtab
/sys/module/xt_state/sections/.symtab
/sys/module/xt_state/sections/.text
/sys/module/xt_state/srcversion
/sys/power
/sys/power/disk
/sys/power/image_size
/sys/power/resume
/sys/power/state
/tmp
/tmp/orbit-OtagoHarbour
/tmp/orbit-OtagoHarbour/linc-48ec-0-d17e592d0ffb
/usr/bin
/usr/bin/dbilogstrip
/usr/lib
/usr/libexec
/usr/libexec/git-core
/usr/lib/mysql
/usr/lib/sse2
/var/cache/man/whatis
/var/db/sudo/OtagoHarbour/0
/var/db/sudo/OtagoHarbour/1
/var/db/sudo/OtagoHarbour/2
/var/lib/dhclient/dhclient-b561f11e-333a-420d-a847-43662ad773ac-eth0.lease
/var/lib/logrotate.status
/var/lib/mlocate
/var/lib/mlocate/mlocate.db
/var/lib/NetworkManager
/var/lib/NetworkManager/timestamps
/var/lib/ntp
/var/lib/ntp/drift
/var/lib/php/session
/var/lib/php/session/sess_0fj5jci0idsh1tjllcmquh4te4

Quote:

Originally Posted by unSpawn

- what (automated?) processes or jobs ran around the mtime?

LAMP (Apache and PHP) Also Anaconda is running and leaving logs.

Quote:

Originally Posted by unSpawn

- user logins around the time?

No user logins since the previous day.

Quote:

Originally Posted by unSpawn

- system / daemon log entries?

[ 91178.816] AUDIT: Sun Mar 30 19:25:31 2014: 1633: client 34 connected from local host ( uid=500 gid=500 pid=7354 )
[ 91202.400] AUDIT: Sun Mar 30 19:25:55 2014: 1633: client 34 disconnected
[ 91223.838] AUDIT: Sun Mar 30 19:26:16 2014: 1633: client 34 connected from local host ( uid=500 gid=500 pid=7364 )
[ 91224.023] AUDIT: Sun Mar 30 19:26:16 2014: 1633: client 34 disconnected
[ 91260.008] AUDIT: Sun Mar 30 19:26:52 2014: 1633: client 34 connected from local host ( uid=500 gid=500 pid=7375 )
[ 91260.160] AUDIT: Sun Mar 30 19:26:53 2014: 1633: client 34 disconnected
[ 93093.992] AUDIT: Sun Mar 30 19:57:26 2014: 1633: client 34 connected from local host ( uid=500 gid=500 pid=7510 )
[ 93094.095] AUDIT: Sun Mar 30 19:57:26 2014: 1633: client 34 disconnected

Thanks,
OH

unSpawn · 04-03-2014, 01:36 AM

I don't know what to make of that. Mtime means file content modification but everything but the mtime seems to agree. Note if file contents change obviously the file hash should change too. Leaving out /sys (it's a VFS like /proc) and /var (volatile contents) this remains:

Quote:

Originally Posted by OtagoHarbour

Code:

/usr/bin
/usr/bin/dbilogstrip
/usr/lib
/usr/libexec
/usr/libexec/git-core
/usr/lib/mysql
/usr/lib/sse2

...which doesn't tell us much except some are part of the base file system package and they shouldn't change unless that package is upgraded. Just to make sure run a 'rpm -Vva|grep -v '^\.\{8\}';'?

OtagoHarbour · 04-03-2014, 10:12 PM

Quote:

Originally Posted by unSpawn

I don't know what to make of that. Mtime means file content modification but everything but the mtime seems to agree. Note if file contents change obviously the file hash should change too. Leaving out /sys (it's a VFS like /proc) and /var (volatile contents) this remains:

...which doesn't tell us much except some are part of the base file system package and they shouldn't change unless that package is upgraded. Just to make sure run a 'rpm -Vva|grep -v '^\.\{8\}';'?

Does it seem suspicious that there was a burst of audit logs that ended just before the file was modified? I tried

Code:

rpm -Vva|grep -v '^\.\{8\}';

and there were pages of files whose dependencies had changed.

I also found this which seems pretty worrying.

Code:

ls -l /usr/bin/dbilogstrip

gives

Code:

-rwxr-xr-x. 1 root root 1465 Mar 30 19:56 /usr/bin/dbilogstrip

I have disabled it for now with

Code:

sudo chmod 0 /usr/bin/dbilogstrip

unSpawn · 04-04-2014, 01:34 AM

Quote:

Originally Posted by OtagoHarbour

Does it seem suspicious that there was a burst of audit logs that ended just before the file was modified?

Unless the unprivileged user transitioned to root, no, on it's own not really.

Quote:

Originally Posted by OtagoHarbour

and there were pages of files whose dependencies had changed.

Filter your output for the ones with the "m" and capital "t" changed?

Quote:

Originally Posted by OtagoHarbour

I also found http://web1.muirfield-h.schools.nsw.edu.au/technology/resources/sdd/sdd923wiki/wiki/upload/coksu.php?act=f&f=dbilogstrip&ft=info&d=%2Fusr%2Fbin"]this which seems pretty worrying.

I can't reach that location so I'd say it's one of those PHP shells. The fact it highlights this particular binary may (or may not) mean anything.

Quote:

Originally Posted by OtagoHarbour

Code:

ls -l /usr/bin/dbilogstrip

gives

Code:

-rwxr-xr-x. 1 root root 1465 Mar 30 19:56 /usr/bin/dbilogstrip

Unless the RPMDB was modified using a rogue package those perms seem to agree with what your RPMDB knows them to be.

If you want to get to the bottom of this there's two things to do: a full audit of the machine, users and any changes and searching the CVE for flaws. Note the original binary you talked about isn't service or a 'net-facing daemon so even if it would be changed the ingress point is Something Completely Different.

OtagoHarbour · 04-19-2014, 07:06 AM

Sorry about my slow reply. I have needed to do some reading to catch up with some of the points you made.

Quote:

Originally Posted by unSpawn

Unless the unprivileged user transitioned to root, no, on it's own not really.

I logged in as root and typed

Code:

history

All I got was the 7 commands I remember entering as root.

Quote:

Originally Posted by unSpawn

Filter your output for the ones with the "m" and capital "t" changed?

I did not get any with the lower case "m" changed. I did get the following.

S.5....T. c /etc/httpd/conf/httpd.conf
.M.....T. /usr/bin/dbilogstrip
..5....T. /usr/share/ibus-table/tables/compose.db
..5....T. /usr/share/ibus-table/tables/latex.db
S.5....T. c /etc/rsyslog.conf
..5....T. c /etc/inittab
S.5....T. c /etc/sudoers
S.5....T. c /etc/tripwire/twpol.txt
missing c /var/run/udev-configure-printer/usb-uris
.M....G.. /var/log/gdm
.M....... /var/run/gdm
missing /var/run/gdm/greeter
S.5....T. c /etc/php.ini

Quote:

Originally Posted by unSpawn

I can't reach that location so I'd say it's one of those PHP shells. The fact it highlights this particular binary may (or may not) mean anything.

That's strange. I did see that it is associated with Apache php.ini which I set up around the time the file was modified. Same evening so was probably around the same time. Specifically, it was associated with the ipays exploit.

Quote:

Originally Posted by unSpawn

If you want to get to the bottom of this there's two things to do: a full audit of the machine, users and any changes and searching the CVE for flaws. Note the original binary you talked about isn't service or a 'net-facing daemon so even if it would be changed the ingress point is Something Completely Different.

I am the only person who logs on to the system although other people would visit the web site that runs on the system. I did an audit using the latest (1.5.0) version of lynis with the following command

Code:

sudo ./lynis --check-all -c -Q

I got the following warnings.

Code:

  - No password set on GRUB bootloader [BOOT-5121]
      http://cisofy.com/controls/BOOT-5121/

  - No password set for single mode [AUTH-9308]
      http://cisofy.com/controls/AUTH-9308/

  - No GPG signing option found in yum.conf [PKGS-7387]
      http://cisofy.com/controls/PKGS-7387/

  - PHP option expose_php is possibly turned on, which can reveal useful information for attackers. [PHP-2372]
      http://cisofy.com/controls/PHP-2372/

and the following suggestions.

Code:

  - Run grub-md5-crypt and create a hashed password. Add a line below the line timeout=<value>, add: password --md5 <password hash> [BOOT-5121]
      http://cisofy.com/controls/BOOT-5121/
  - Run chkconfig --list to see all services and disable unneeded services
      http://cisofy.com/controls/[07:12:38 Suggestion: Run chkconfig --list to see all services and disable unneeded services/
  - Configure password aging limits to enforce password changing on a regular base [AUTH-9286]
      http://cisofy.com/controls/AUTH-9286/
  - Set password for single user mode to minimize physical access attack surface [AUTH-9308]
      http://cisofy.com/controls/AUTH-9308/
  - To decrease the impact of a full /home file system, place /home on a separated partition [FILE-6310]
      http://cisofy.com/controls/FILE-6310/
  - To decrease the impact of a full /tmp file system, place /tmp on a separated partition [FILE-6310]
      http://cisofy.com/controls/FILE-6310/
  - Disable drivers like USB storage when not used, to prevent unauthorized storage or data theft [STRG-1840]
      http://cisofy.com/controls/STRG-1840/
  - Disable drivers like firewire storage when not used, to prevent unauthorized storage or data theft [STRG-1846]
      http://cisofy.com/controls/STRG-1846/
  - Split resolving between localhost and the hostname of the system [NAME-4406]
      http://cisofy.com/controls/NAME-4406/
  - Access to CUPS configuration could be more strict. [PRNT-2307]
      http://cisofy.com/controls/PRNT-2307/
  - Check iptables rules to see which rules are currently not used [FIRE-4513]
      http://cisofy.com/controls/FIRE-4513/
  - Install Apache mod_evasive to guard webserver against DoS/brute force attempts [HTTP-6640]
      http://cisofy.com/controls/HTTP-6640/
  - Install Apache mod_qos to guard webserver against Slowloris attacks [HTTP-6641]
      http://cisofy.com/controls/HTTP-6641/
  - Install Apache mod_spamhaus to guard webserver against spammers [HTTP-6642]
      http://cisofy.com/controls/HTTP-6642/
  - Install Apache modsecurity to guard webserver against web application attacks [HTTP-6643]
      http://cisofy.com/controls/HTTP-6643/
  - Harden PHP by disabling risky functions [PHP-2320]
      http://cisofy.com/controls/PHP-2320/
  - Change the expose_php line to: expose_php = Off [PHP-2372]
      http://cisofy.com/controls/PHP-2372/
  - Change the allow_url_fopen line to: allow_url_fopen = Off, to disable downloads via PHP [PHP-2376]
      http://cisofy.com/controls/PHP-2376/
  - Check what deleted files are still in use and why. [LOGG-2190]
      http://cisofy.com/controls/LOGG-2190/
  - Add legal banner to /etc/motd, to warn unauthorized users [BANN-7122]
      http://cisofy.com/controls/BANN-7122/
  - Add a legal banner to /etc/issue, to warn unauthorized users [BANN-7126]
      http://cisofy.com/controls/BANN-7126/
  - Add legal banner to /etc/issue.net, to warn unauthorized users [BANN-7130]
      http://cisofy.com/controls/BANN-7130/
  - Audit daemon is enabled with an empty ruleset. Disable the daemon or define rules [ACCT-9630]
      http://cisofy.com/controls/ACCT-9630/
  - Check ntpq peers output for unreliable ntp peers and correct/replace them [TIME-3120]
      http://cisofy.com/controls/TIME-3120/
  - Some time servers missing in step-tickets file [TIME-3160]
      http://cisofy.com/controls/TIME-3160/
  - One or more sysctl values differ from the scan profile and could be tweaked [KRNL-6000]
      http://cisofy.com/controls/KRNL-6000/
  - Harden the system by removing unneeded compilers. This can decrease the chance of customized trojans, backdoors and rootkits to be compiled and installed [HRDN-7220]
      http://cisofy.com/controls/HRDN-7220/
  - Harden compilers and restrict access to world [HRDN-7222]
      http://cisofy.com/controls/HRDN-7222/
  - Harden the system by installing one or malware scanners to perform periodic file system scans [HRDN-7230]
      http://cisofy.com/controls/HRDN-7230/

Thanks,
OH

unSpawn · 04-24-2014, 01:03 AM

Quote:

Originally Posted by OtagoHarbour

All I got was the 7 commands I remember entering as root.

OK.

Quote:

Originally Posted by OtagoHarbour

I did not get any with the lower case "m" changed. I did get the following.

Code:

.M.....T.    /usr/bin/dbilogstrip
..5....T.    /usr/share/ibus-table/tables/compose.db
..5....T.    /usr/share/ibus-table/tables/latex.db
..5....T.  c /etc/inittab
S.5....T.  c /etc/tripwire/twpol.txt

Configuration files do change though, as with any other changed file, only a visual inspection of changes (or comparison with known clean copies of a file in case of a binary) will tell you if they are authorized or not.

Quote:

Originally Posted by OtagoHarbour

That's strange. I did see that it is associated with Apache php.ini which I set up around the time the file was modified. Same evening so was probably around the same time. Specifically, it was associated with the ipays exploit.

Care to elaborate?

Quote:

Originally Posted by OtagoHarbour

I am the only person who logs on to the system although other people would visit the web site that runs on the system. I did an audit using the latest (1.5.0) version of lynis with the following command

Lynis is more akin to GNU/Tiger IIRC which should be valuable to run when you harden a machine before exposing it to the 'net.

Quote:

Originally Posted by OtagoHarbour

I got the following warnings. (..) and the following suggestions.

Maybe a stupid question but did you follow up on those warnings / suggestions? Mind you, not all relate to security aspects and none will help you understand what happened here (as would using the system and making any changes while investigating).

Given the details you have presented I'm more thinking this is is some flaw in TW.

OtagoHarbour · 05-04-2014, 09:46 PM

Sorry again about the delay.

Quote:

Originally Posted by unSpawn

Configuration files do change though, as with any other changed file, only a visual inspection of changes (or comparison with known clean copies of a file in case of a binary) will tell you if they are authorized or not.

I can under stand /etc/tripwire/twpol.txt changing.
/usr/share/ibus-table/tables/compose.db,
/usr/share/ibus-table/tables/latex.db and
/etc/inittab
were dated March 25. I did not think I had even installed the system until March 27. Maybe I installed it on March 27 and they were updated with the installation.

Quote:

Originally Posted by unSpawn

Care to elaborate?

The link no longer works for me either now. Maybe it's erratic but I have not found anything else linking dbilogstrip with malware.

Quote:

Originally Posted by unSpawn

Maybe a stupid question but did you follow up on those warnings / suggestions? Mind you, not all relate to security aspects and none will help you understand what happened here (as would using the system and making any changes while investigating).

I've been working through the suggestions. I turned off the services that I do not appear to need. The GRUB password seems to only apply to when a bad guy has physical access to my machine. I will work through the other suggestions on the list.

Quote:

Originally Posted by unSpawn

Given the details you have presented I'm more thinking this is is some flaw in TW.

Thanks. I chmod'ed /usr/bin/dbilogstrip to zero about a month ago and it still has the date and time of when I did so.

Thanks again,
OH