I have been attacked and don't know why.

[gonk]

Here's what I found

• two hidden directories in /var/tmp with contents looking like phishing for bank details
  removed!
• /var/lock/ttoy being pretty empty except for hidden directories
  removed!
• /var/lib/apache2/fastcgi contains the following with the same timestamp as the /var/lock/ttoy above
  srwxrwx--- 1 root www-data 0 Nov 11 21:22 fcgi
  Should they be removed?

For some reason I had 11 apache2 instances running as www-data despite rebooting after applying 2.6.0.1 and having removed cron-jobs for www-data etc. After yet another reboot there are now 6 instances of apache2 running, probably mapping to the admin interface, the album, file manager, /home/web and other defaults.

... but I'm grateful for any hint on how to detect if any of these ar not ok and how to locate their configuration files etc.

I found that /etc/apache2/cacert.pem is updated yesterday morning.
Is that of any relevance?

I suppose that the updated /etc/apache2/conf.d/admin.conf is due to the 2.6.0.1 update.

[Ubi]

the 6 instances is not what you think, it is just that apache has 6 child process available that listen to new connections. This is normal.

As for the fcgi, that is a bit weird, especially because it is owned by root. I do not have this file on my system. You can see if it is important by disabling its execution (chmod a-x fcgi). THe cert date is also weird

THe thing is, if the attacker managed to create a file owned by root, it means the box is fully compromised. However, if that were the case, an attacker would not really bother around changing cacerts and hiding files in silly locations. In the off chance your web server got rooted you can see if they added configs to /etc/apache2/. (running "apache2ctl -St" is a good start)

[Gordon]

Here's what I found

• two hidden directories in /var/tmp with contents looking like phishing for bank details
  removed!
• /var/lock/ttoy being pretty empty except for hidden directories
  removed!
• /var/lib/apache2/fastcgi contains the following with the same timestamp as the /var/lock/ttoy above
  srwxrwx--- 1 root www-data 0 Nov 11 21:22 fcgi
  Should they be removed?

That last "file" is the fcgi socket that you need for the webadmin interface. It won't be of much use to a hacker since it only applies to the location of the webadmin and this is root owned (i.e www-data cannot inject other php scripts in that location)

For some reason I had 11 apache2 instances running as www-data despite rebooting after applying 2.6.0.1 and having removed cron-jobs for www-data etc. After yet another reboot there are now 6 instances of apache2 running, probably mapping to the admin interface, the album, file manager, /home/web and other defaults.

That is normal for Apache. It is not related to any specific vhost instance or web folder.

... but I'm grateful for any hint on how to detect if any of these ar not ok and how to locate their configuration files etc.

See previous answer.

I found that /etc/apache2/cacert.pem is updated yesterday morning.
Is that of any relevance?

That I guess would be a coincidence. It probably expired and was replaced by the update for that reason.

I suppose that the updated /etc/apache2/conf.d/admin.conf is due to the 2.6.0.1 update.

The data stamp suggests so yes, but it doesn't seem changed to me. Annoyingly some of the config scripts in the webadmin have been changed, so now my alternate root is misformatted (again )

[Ubi]

ah yes I overlooked that this fcgi was in another location. Please ignore my previous post.

[Gordon]

THe thing is, if the attacker managed to create a file owned by root, it means the box is fully compromised. However, if that were the case, an attacker would not really bother around changing cacerts and hiding files in silly locations. In the off chance your web server got rooted you can see if they added configs to /etc/apache2/. (running "apache2ctl -St" is a good start)

I talked to a friend yesterday and on his B3 the root password had been changed (he hadn't bothered to change it from default). Now that's a real dead give away.

[Ubi]

If this is really true, this does mount to the suggestion that the attacker knows he's on a B23. Has there been malicious content on that machine owned by root?

The reason why I'm skeptical is that specifically attacking B23 is not a very smart move, considering the install base is not gigantic and they are generally on consumer-grade DSL lines.

[Ubi]

Another new security measure would of course be to limit "su" to a specific group in which no daemons are allowed.

[gonk]

If this is really true, this does mount to the suggestion that the attacker knows he's on a B23. Has there been malicious content on that machine owned by root?

That's horrible!

My first B3 had a faulty motherborad failing to do gigabit speed networking and after getting it replaced I forgot to change the root password, which caused an incident when I allowed Excito support access via ssh to fix another thing later. After that I've definitely not running on the default root password and I didn't see any changes to /etc/passwd but I'll take a closer look tonight. At least my root password still works so that has not been changed.

[gonk]

Another new security measure would of course be to limit "su" to a specific group in which no daemons are allowed.

That seems like a relevant default setting unless it would make it impossible for the web interface to update the installation. In such case I'd rather opt for a manual commandline update function manually run as root and additional security rather than the convenience of a web update function.

[Ubi]

it should not interfere.
The thing with manual updates is that for many users this is too difficult to bother, resulting in unpatched machine

[Gordon]

If this is really true, this does mount to the suggestion that the attacker knows he's on a B23. Has there been malicious content on that machine owned by root?

May be, but IMO not likely. They'll most likely attempt a list of known default passwords. However changing the root password is not exactly best practice for hiding that you were there, so that might imply that he/they is purposely targeting machines that are not actively administered.

As far as bandwidth is concerned DSL may suit the hacker's intentions fine enough. The limited CPU power will probably also be of no concern; it can still participate in the higher goal together with all the other machines that have been compromised.

[Gordon]

Another new security measure would of course be to limit "su" to a specific group in which no daemons are allowed.

That seems like a relevant default setting unless it would make it impossible for the web interface to update the installation. In such case I'd rather opt for a manual commandline update function manually run as root and additional security rather than the convenience of a web update function.

The admin interface does not run as www-data but as root - that is the whole purpose of the fcgi thing

[Ubi]

I never looked into this in detail but I always thought the frontend ran as unprivileged and requested changes to a daemon that was running as root. Apparently not. In both cases changing su to an owner group is not related to this

[ryz]

[quote="Ubi"The reason why I'm skeptical is that specifically attacking B23 is not a very smart move, considering the install base is not gigantic and they are generally on consumer-grade DSL lines.[/quote]

Even if the original attack was not for the B2 or B3 there is always a chance that some one reading this thread decided that it wanted to test the dark side and try to hack into B2:s and B3:s. Either for machines that he already had access for or he find a way to get hold of addresses to some B2:s or B3:s.

[Ubi]

In that case, the log files on the DNS server can tell us who that is =)