Sicherheitslücke horde3

Hallo,

Kann es sein, dass horde3 auf LML6.2 in der offiziellen Konfiguration nach dieser Seite eine Angriffsmöglichkeit bietet?
https://securitynews.sonicwall.com/xmlpost/hackers-actively-scanning-for-horde-imp-vulnerability/

Danach sollte man …/horde3/imp/test.php löschen, oder?

Gruß

Martin

Hallo Martin!

Wenn deine Horde über das Internet zu erreichen ist, würde ich "Ja, auf alle Fälle! sagen.
Wenn sie nur im Intranet zu erreichen ist, dann ein Ja.

Besser umbenennen und/oder die Rechte (600) verändern, dann hast Du sie falls sie nochmal gebraucht wird.

Beste Grüße

Thorsten

Hallo,

ich habe sie gelöscht.
Es sei darauf hingewiesen, dass es nicht nur:
/usr/share/horde3/imp/test.php
, sondern auch:
/usr/share/horde3/test.php

ich habe beide Gelöscht und empfehle es jedem der eien lmn6.2 laufen hat die über http oder https vom INternet aus erreichbar ist!

LG

Holger

Hallo,

ich würde davon ausgehen, dass Horde mit einer nicht mehr supporteten PHP Version sowieso ein unkalkulierbares Risiko darstellt. Wenn man das nicht benutzt (wovon man letztlich nur abraten kann), kann man auch einfach den Link /etc/apache2/conf.d/horde löschen und den Apachen neu starten, dann ist Horde generell nicht mehr erreichbar.

VG

Frank

Hallo!
Wenn man das nur intern benutzt (Medienbildung Klasse 5: E-Mails), MRBS aber auch nach außen, wie kann man dafür sorgen, dass Horde3 nur intern geht, MRBS und Schulportfolio aber weiterhin von außen verfügbar sind?
LG
Max

Hallo Max,

dann müsstest Du für jeden dieser Dienste einen eigenen Virtual Host definieren und die diesbezügliche Konfiguration dorthin verschieben. Bei einem Virtual Host kann man festlegen, auf welchem Interface er lauscht.

Beste Grüße

Jörg

Hallo Max,

Wenn man das nur intern benutzt (Medienbildung Klasse 5: E-Mails), MRBS
aber auch nach außen, wie kann man dafür sorgen, dass Horde3 nur intern
geht, MRBS und Schulportfolio aber weiterhin von außen verfügbar sind?

.htaccess Datei, die die erlaubten IP Adressbereiche einschränkt.

LG

Holger

1 Like

/etc/horde/apache2.conf muss man für root schreibbar machen

dann:

#access from all
access from 10.16.0.0/255.240.0.0

funktioniert zumindest jetzt von außen nicht mehr.

von innen schau ich mir noch an und berichte.

vG, Tobias

Hallo Tobias,

vielleicht könntest du bei der Gelegenheit auch schauen, ob Weiterleitungen nach außen (z. B. Mails an den administrator) dann noch funktionieren.

Viele Grüße

Wilfried

Hallo Wilfried,
kann ich nicht so einfach, weil bei mir das sowieso abgestellt ist.
Aber ich kann mir beim besten Willen nicht vorstellen, dass das nicht klappen sollte. Mails nach draußen gehen ja nicht über http sondern über smtp (ganz anderer port) und dann müssen sie ja auch über einen smtp-server (auch andere Baustelle).
Das muss also bei allen weiterhin klappen, wenn es bisher klappte.
VG, tobias

Hallo Tobias,

eine /etc/horde/apache2.conf gibt es bei mir nicht, sondern nur eine /etc/horde/apache.conf, und an der kann ich ändern, was ich will: Es hat keinerlei Auswirkungen. Wahrscheinlich weil sie sich auf die falsche apache-Version bezieht.
Anders die Datei /usr/share/horde3/imp/.htaccess, in der ich z. B. den Zugang für Schüler sperren kann: Require ldap-attribute gidNumber=10000.
Wenn ich hier allerdings mit Order deny, allow usw. etwas ergänze, dann ist horde weder intern noch extern zugänglich.

Viele Grüße
Wilfried

Hallo Tobias,

es geht doch mit der /etc/horde/apache.conf, und zwar mit dem Eintrag
allow from 10.16.0.0/255.240.0.0
… wenn man nicht vergisst, den apache neu zu starten :wink:

Viele Grüße
Wilfried

Ob ihr bereits Opfer geworden seit, findet ihr so raus:

  • In /var/log/apache2/access.log finden sich Einträge wie
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"](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)" 
  • Eventuell wollte der Angreifer mails versenden:
mailq
  • mails aus der mailq löschen
 mailq | tail +2 | grep -v '^ *(' | awk 'BEGIN { RS = "" } { if ($8 == ["www-data@kg-fds.de"](mailto:www-data@kg-fds.de)) print $1 }' | tr -d '*!' | postsuper -d -
  • Apache WebServer stoppen
service apache2 stop
  • Prozessse von www-data killen
ps aux|grep ^www-data|cut -d " " -f 2
ps aux|grep ^www-data|cut -d " " -f 3

liefert die PID der Prozesse, diese mit

kill -9 PID

killen

Da Horde3 (wie oben beschrieben) schon etwas in die Jahre gekommen ist, habe ich bei mir das Verzeichnis /usr/share/horde3 mit einer .htaccess-Datei geschützt, so dass nur User überhaupt die Seite aufrufen können:

# Authentifizierungsmodus

AuthType Basic 

# Titel des Authentifizierungsfensters

AuthName WebMailer_KGy

# Angabe des Authentifizierungsanbieters

AuthBasicProvider ldap

# erm�glicht die Zulassung von allen LDAP-Nutzern ohne Angabe einer speziellen Gruppe

AuthzLDAPAuthoritative off

# URL zum LDAP-Server

AuthLDAPURL ldaps://localhost/ou=accounts,dc=server,dc=de?uid

                                                                                                                                                                                                

# Zulassung aller User auf dem LDAP-Server                                                                                                                                                      a

require valid-user  

Hallo und Danke für die Tipps!

Ich bin wohl betroffen, denn ich habe solche Einträge:

Gemerkt habe ich, dass die Schulkonsole langsamer wurde und vor allem ein Import der Hosts sehr lange dauerte. Nach den u.a. Maßnahmen läuft das jetzt wieder deutlich schneller.

Bin ich sicher, wenn ich nichts mit htaccess gemacht habe (weil ich davon keine Ahnung habe), aber das folgende gemacht habe?

  • apache angehalten
  • alle Prozessse von www-data gekillt
  • komplette mailq gelöscht:
    postsuper -d ALL
  • /etc/horde/apache.conf so editiert:
    #access from all
    access from 10.16.0.0/255.240.0.0
  • /usr/share/horde3/imp/test.php umbenannt
  • /usr/share/horde3/test.php umbenannt
  • apache gestartet

Für Einschätzungen dankbar!
Stefan

Hallo Stefan,

ich habe zusätzlich im Ipfire GeoIP Block eingeschaltet und nur die Länder die notwendig sind zugelassen.

Damit hatte der Spuk ein Ende, denn die Versuche wurden nach Deinen Maßnahmen immer noch gestartet.

Gruß

Alois