Rejtélyes fájlátnevezés valami.php-ról valami.php.suspected-re

Linux-security

Sziasztok!

Egy nagyon érdekes esettel találkoztam a napokban.

Van egy Debian Jessie szerver, mely weboldalakat hosztol. Főként CMS-eket, WordPress-szeket.

Előfordul olykor, hogy bizonyos fájlokat valami átnevez pl.: wp-db.php-ről wp-db.php.suspected-re. A legutóbbit ftp-n át történő feltöltéskor nevezte át, és benne is van a ProFTPd transfer logban. Mindezt úgy, hogy abban a fájlban semmi gyanús nincs, viszont a szájt persze lehal nélküle. De előfordult már, hogy ténylegesen ártalmas kódot tartalmazó fájlt talált meg és nevezett át.

Van a rendszeren telepítve ClamAV, chkrootkit, rkhunter és maldetect. Először a ClamAV-ra gyanakodtam, de az nem rezidens víruskergető, így az nem nevezné át a fájlokat menet közben. A maldetectben pedig nem láttam ilyen funkciót.

Kis kutakodás után a Google megmutatja, hogy jópár embernek volt már ugyanez a problémája különböző CMS-ekkel és rendszerekkel, de az okozója nem igazán világos.

Látott már valaki hasonlót, vagy van ötlete, hogy mi okozhatja ezt a viselkedést?

Előre is köszi a segítséget!

( bandy | 2016. 01. 12., k – 11:39 )

Egyes FTP kliensek feltolteskor ideiglenes nevvel feltoltik az uj verziot, letorlik a regit es atnevezik amit feltoltottek. Ez hasznos, ha lassu kapcsolaton nagy fileokat kell felrakni elo oldalra.
Ha atnevezes kozben megszakad a kapcsolat, akkor a regi MAR torolve, az uj MEG nincs atnevezve.

Igen, én magam is gyanakodtam az FTP kliensre, de kipróbáltuk többfélével is (Krusader, FileZilla) és másodszori feltöltésnél semmi nyoma, hogy bármi randalírozna a szerveren. Plusz az az előbb kimaradt, hogy a fájlokat Ubunturól töltik fel programozók, úgyhogy még az sincs, hogy kliens oldalon piszkálna bele valami AV.

( Atekka | 2016. 01. 12., k – 11:48 )

A stat parancs megmondja mikor lett modified utoljara a time stampbol kiindulva lehet kutakodni egy kicsit. Vagy monitorozd a fajlrendszert valamivel es az majd szol ki a ludas.

( Frantique v | 2016. 01. 12., k – 11:51 )

Az ok: "After some more research on this, this is a wide-spread issue across hacked sites. Why hackers would re-name legitimate files to .php.suspected is beyond me but I have confirmed this is happening on hacked sites via requests to malicious files."

--
Coding for fun. ;)

Köszönöm a tippet! Ezt a fórumtémát olvastam az elsők között, és két kérdés merült fel bennem:

1. Ha én feketekalapos hacker lennék és spamet küldenék, vagy bármi más ártalmasat csinálnék egy feltört szerveren, akkor ugyebár az lenne az első dolgom, hogy minél jobban elrejtsem a kódjaimat, tevékenységemet. Méigs ennek tudatában vajon mi okom lenne rá, hogy átnevezzem a sikeresen feltört fájlaimat valami.php.gyanus-ra?
2. Mi van az olyan szájtok esetében, amelyek nem tűnnek feltörtnek? Értsd: semmi gyanúsat nem csinál, nem spammel, nem használja jobban az erőforrásokat, mind eddig.

Lássuk csak... a való életben bizonyos vándor csoportok "megjelölik" a kiszemelt házakat (a falra rajzolnak, jelölik az ajtót stb.).
Ha én feketekalapos hacker lennék, akkor így csinálnám:

1. Szkennelnék egy tartományt, és vulnerábilis rendszereket keresve átneveznék egy adott fájlt/fájlokat olyanra, amit ellenőrizni tudok, hogy ott van-e.
2. A megjelölt szervereket menteném a későbbiekre.
3. Várnék egy ideig, hogy lássam, mit lépnek a rendszergazdák.
4. A kijavított, kezelt szervereket többet nem bántanám (rizikós, hogy lyukra futok).
5. A türelmi időn túl még mindig nem rendberakott szervereket menteném.
6. Ha bármikor kell egy botnet, felélesztem a nem karbantartott szervereket.

--
Coding for fun. ;)

Ez egy nagyon jó meglátás! Ennek ellenére mégis úgy gondolom, hogyha már szert tesznek olyan tudásra, amivel képesek automatizált módon rendszereket feltörni, vagy akárcsak kézileg is, akkor csak nem azon buknak el, hogy egy olyan fájlt neveznek át (wp-db.php), amelynek hiányában az egész szájt lehal, és vagy az ügyfél, vagy a rendszergazda kapásból észreveszi és visszanevezi, plusz elkezd gyanakodni, hogy valami nem oké. Mert ha készítenének egy /wp-content/themes/twentytwelve/readmeall, vagy hasonló fájlt, ami a kutyának nem tűnik fel, arra még azt mondanám, hogy oké.

Nos, jobban belegondolva a folyamatokba, úgy gondolom, hogy inkább egy FÉLBESZAKADT törés nyomait látod, nem a végeredményt. Inkább az az aggasztó, hogy ezt hogy csinálták, ennek kéne a nyomára akadni. Visszaállítod a sz*t, és újra megtörnek. Jó játék. (Láttam már olyan rendszert a pályafutásom alatt, ahol visszatérőként havonta elvitték a teljes adatbázist sql injectionnal - mindezt másfél éve csinálták rendszeresen.)

Jó lenne megnézni, hogy mi bújik még a rendszeren, mielőtt nekiállnál törölni/átnevezni, akkor tudnék többet mondani.

--
Coding for fun. ;)

( manfreed (nem ellenőrzött) | 2016. 01. 12., k – 14:25 )

"A legutóbbit ftp-n át történő feltöltéskor nevezte át, és benne is van a ProFTPd transfer logban"

Lehet hülye kérdés, de nem képzelhető el, hogy a kliens gépen nevezte át valami (aki a feltöltést végezte?)