Arch Linux

RarefiedOwlEgg

Member

Registered: 2023-07-11

Posts: 3

Perl DDoS bot in /var/lib/postgres

When going to upgrade Postgres today, I was greeted with a curious and unpleasant surprise.  In the /var/lib/postgres directory, I noticed a directory named just ' ' (a single space).  The contents of this directory:

[root@jakarta postgres]# ls -lah ' '
total 88K
drwxr-xr-x  2 postgres postgres 4.0K Feb 10  2019 .
drwxr-xrwx 10 postgres root     4.0K Oct 28  2022 ..
-rw-r--r--  1 postgres postgres  39K Apr 25  2017 .bin.txt
-rw-r--r--  1 postgres postgres  40K Apr 15  2018 perl.tar

Where .bin.txt seems to be the untared  contents of perl.tar and is a variation of the "DDoS Perl IrcBot", similar (but slightly different) to what's here here. 

I'm wondering what might have happened here and whether I need to wipe and reinstall.  This is my main workstation, behind NAT, and I'm generally cautious about installing software from untrusted sources. 

In particular, how, of all places, did these files end up in /var/lib/postgres and owned by the postgres user?  Nothing is running as that user but postgres of course.  I'm stumped.

Edit: to correct the path from /var/postgres to /var/lib/postgres

Last edited by RarefiedOwlEgg (2023-07-11 16:18:40)

Trilby

Inspector Parrot

Registered: 2011-11-29

Posts: 30,330

Website

Re: Perl DDoS bot in /var/lib/postgres

And what interacts with that database?  Is there any external access to the database?  And if so, do you sanitize input / queries properly?  EDIT: these questions should also apply to the historical state of this machine as - if those dates are to be trusted - that content has been there for (at least) 6+ years.

Last edited by Trilby (2023-07-11 16:28:46)

---

"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman

RarefiedOwlEgg

Member

Registered: 2023-07-11

Posts: 3

Re: Perl DDoS bot in /var/lib/postgres

Nothing external to the machine should be interacting with postgres.  The databases there are used only for local testing and for recording data by programs I wrote myself.  My pg_hba.conf - allows only local connections.  And in any case, would a SQL injection attack even be able to create files in this location? 

That said, the point about the historical state of the machine is definitely important because it's been a long time and it's impossible to recall everything I've done since then. 

The original build and install date of this machine was May 2018, so both of those file dates predate this and I don't give them much credence.