Kurztipp: PHP Shells mit maldet finden

Maldet ist ein Malware Scanner. Ideal für jegliche Art von Webhosting.

Maldet legt automatisch einen cronjob an und verschickt je nach Wunsch täglich mails.

Mails sehen dann in etwa so aus:

HOST:      web01
SCAN ID:   170610-0654.14910
STARTED:   Jun 10 2017 06:54:15 +0200
COMPLETED: Jun 10 2017 07:07:34 +0200
ELAPSED:   799s [find: 450s]

PATH:          
RANGE:         1 days
TOTAL FILES:   24202
TOTAL HITS:    2
TOTAL CLEANED: 0

WARNING: Automatic quarantine is currently disabled, detected threats are still accessible to users!
To enable, set quarantine_hits=1 and/or to quarantine hits from this scan run:
/usr/local/sbin/maldet -q 170610-0654.14910

FILE HIT LIST:
{HEX}php.cmdshell.unclassed.365 : /pfad/zum/docroot/phpshells/844-4873-1-SM.phtml
{HEX}gzbase64.inject.unclassed.15 : /pfad/zum/docroot2/c.php

Maldet bietet etliche Einstellungsmöglichkeiten.  Man kann es auch in Echtzeit im monitoring mode laufen lassen. Je nach Umfang der docroots stößt man dabei aber an diverse Limits (ulimit &co).

Auf Github findet man Maldet unter https://github.com/rfxn/linux-malware-detect. Debian Pakete gibt es unter https://github.com/waja/maldetect.

Kurztipp: Spam Versand ermöglichen

Will man externen den Versand von Spam über den eigenen Server ermöglichen, kann man dafür eine nicht mehr gepflegte Gallery2 Installation bereitstellen.
Geholfen hat ein  Nagios Check für die  mailq und php maillog in der php.ini zu aktivieren. Schnell bemerkt, schnell behoben, trotzdem ärgerlich da in den ca. 30 Minuten doch einiges an Spam raus ging.
Daher mein Tipp: Software, die nicht mehr genutzt wird, löschen oder hinter htaccess packen.

Kurztipp: Die IP bei ausgehenden Mails entfernen

Um die Sender-IP bei ausgehen mails zu entfernen nutze ich folgendes unter Postfix:

In die /etc/postfix/master.cf

submission inet n - - - - smtpd

...

-o cleanup_service_name=subcleanup

subcleanup unix n - - - 0 cleanup
-o header_checks=regexp:/etc/postfix/submission_header_checks

Und in der /etc/postfix/submission_header_checks


/^Received: .*/ IGNORE
/^X-Originating-IP:/ IGNORE

 

Ich versende über den Submission Port 587.  DKIM, SPF & Co sind davon unbeeinflusst und tun weiter ihr Werk.

 

 

Kurztipp: nmap range scan heartbleed

Mit nmap lässt sich relativ unkompliziert ein range scan auf den heartbleedbug durchführen, dazu ist aber eine aktuelle nmap Version nötig:

wget http://nmap.org/dist/nmap-6.45.tar.bz2
bzip2 -cd nmap-6.45.tar.bz2 | tar xvf -
cd nmap-6.45/
./configure
make

wer es dann noch installieren will kann ein

make install 

ausführen, womit nmap nach usr/local/bin/ installiert wird, ansonsten liegt die nmap binary direkt im Ordner und kann z.B. mit

./nmap -sV -p 443,10000 --script=ssl-heartbleed.nse 123.123.123.1/24 

aufgerufen werden. Ein Scan durch ein ganzes Subnetz kann schon ein paar Minuten dauern und treibt die Last der Maschine recht hoch. Also am besten auf parallele Prozessese verzichten. Die Portliste kann man natürlich noch um diverse Ports erweitern (443, 993, 25, 465 usw.).
Bei Erfolg sieht das Ergebnis in etwa so aus:

...
Host is up (0.0014s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-heartbleed:
|   VULNERABLE:
|   The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
|     State: VULNERABLE
|     Risk factor: High
|     Description:
|       OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|
|     References:
|       http://cvedetails.com/cve/2014-0160/
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
|_      http://www.openssl.org/news/secadv_20140407.txt
...

Noch ein Hinweis…liebe Webmin Benutzer denkt daran Webmin neu zu starten, denn das ist natürlich auch vom Bug betroffen.

Links:

http://nmap.org/download.html

http://www.cirgan.net/scanning-openssl-heartbleed-bug-with-nmap/

Kurztipp: Heartbleed und kein Ende

Denen, die NAS Systeme zu hause betreiben und das Webinterface aus Bequemlichkeit von 0/0 erreichbar gemacht haben, sei gesagt: Euer NAS ist höchstwahrscheinlich auch vom Heartbleed Bug betroffen.

Getestet habe ich bisher nur ein altes QNAP 219 mit Version 4.05 und ein QNAP 469L mit 4.06. Ich denke aber, dass so ziemlich jedes QNAP NAS (Synology & co sicherlich auch) mit der 4er Firmware betroffen ist. Updates habe ich bisher noch keine dafür gesehen. Am besten also den Zugriff beschränken oder komplett von außen sperren. Problematisch wird es bei billig NAS Systemen, wo Softwareupdates eher die Ausnahme sind. Das gleiche gilt natürlich auch für eure Raspberry Pis & co. Bei Raspbmc ist ein komplettes upgrade/ dist-upgrade eher nicht zu empfehlen. Da sollte ein

apt-get update && sudo apt-get --only-upgrade install openssl

reichen. Da kommt sicherlich noch viel mehr und das Netz wird zur Zeit voll von Scans sein. Mich würde interessieren ob ein massiver Scan auf verwundbare Systeme irgendwelche Auswirkungen zeigt, also Anstieg der Load zum Beispiel.
Ist man neugierig wer so alles den Heartbleed Bug bei seinen Systemen versucht kann folgendes versuchen:

# Log rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"

# Block rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Die erste Regel logt Versuche nach syslog (oder /varog/warn bei Suse), die zweite sperrt 443 für Exploit Versuche (via https://plus.google.com/+MatthewSummers/posts/jiZdHvuHq69 und zu finden unter http://seclists.org/fulldisclosure/2014/Apr/109)

….ach da kommt bestimmt noch viel mehr in naher Zukunft.

update: Mittlerweile gibt es die FW4.07 für das QNAP 469L, damit ist die Lücke geschlossen. Für das QNAP 219 gibt es leider nichts.

 

längerer Kurztipp: Schutz gegen einfache DOS Attacken mit mod_evasive

Ein alter Hut, ich kannte es bis heute nicht. Mit mod_evasive kann man einfache DOS Angriffe blocken. Getestet mit dem guten, alten Squeeze.

$ apt-get install libapache2-mod-evasive
$ a2enmod mod-evasive
$ zless /usr/share/doc/libapache2-mod-evasive/README.gz
$ mkdir /var/log/mod_evasive
$ chown www-data /var/log/mod_evasive
$ ln -s /usr/bin/mail /bin/mail

$ joe /etc/apache2/mods-available/mod-evasive.conf

<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive
DOSEmailNotify thisis@waste.land
DOSWhitelist 127.0.0.1
</ifmodule>

$ ln -s /etc/apache2/mods-available/mod-evasive.conf /etc/apache2/mods-enabled/mod-evasive.conf
$ /etc/init.d/apache2 reload

Zum testen einfach mal irgendeine Seite aufrufen und ein paar mal schnell F5 drücken bis man ein 403 Forbidden erhält. Dann im logdir schauen und eigentlich sollte man auch eine mail bekommen. Im syslog sollte ein Eintrag der Art
Mar 14 11:36:15 webserver  mod_evasive[15723]: Blacklisting address 123.123.123.123: possible DoS attack
aufauchen.
Mit DOSSystemCommand kann man noch einen Befehl definieren, der ausgeführt werden soll wenn eine IP geblockt wird, also z.B. iptables Regel zum sperren der IP („sudo /sbin/iptables -A INPUT -s %s -j REJECT„) oder was auch immer.
Die Meinungen zum Einsatz von mod_evasive gehen etwas auseinander, daher sollte man es erst mal  unter Beobachtung laufen lassen und am besten vorher mal ein bisschen googlen.
Zusammen mit HAproxy oder Nginx als Reverseproxy funktioniert mod_evasive nicht. Da kann man sich  mal das Nginx Modul HttpLimitReq anschauen. mod_evasive blacklisted zwar die IPs, mehr aber leider nicht.

Links:

http://www.linux-magazin.de/Ausgaben/2005/12/Friede-im-Indianerland

http://pc-freak.net/blog/secure-apache-against-basic-denial-of-service-attacks-with-mod_evasive-on-debian/

http://spielwiese.la-evento.com/xelasblog/archives/56-Apache-DOS-Attacken-erschweren-mit-mod_evasive.html

Apache Killer Abwehr

Ohne Gewaehr. Sinnig wenn man mehre Vhosts hat und nicht jede vhost.conf anpassen will. Gefaellt mir besser als die Rewrite Workarounds.

in /etc/apache2/conf.d

eine Datei fix.conf anlegen mit folgendem Inhalt:

SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

danach

a2enmod headers

und

/etc/init.d/apache2 restart

Waere gut wenn das jemand validieren koennte. Bei mir funktioniert es jedenfalls.

Links:

sperr mich ein Baby

Chroot ist gut, so einfach ist das. Multiusersysteme ohne chroot bieten ein grosses Sicherheitsrisiko. Dieses Risiko entsteht in der Regel durch falsch gesetzte Dateirechte. Leider kann mit vertretbaren Mitteln nicht überall eine chroot Umgebung aufgebaut werden. Generell sollte man sich immer Fragen: Braucht der Benutzer ueberhaupt eine Shell? Nehmen wir einen standard Webserver mit mehreren virtuellen Webservern und unterschiedlichen Benutzern als Beispiel. Der Benutzer will Daten auf den Webserver ablegen, die darüber bereitgestellt werden, mehr nicht. Eine Shell ist dabei voellig unnötig und erhöht nur das Risiko eines potentiellen Einbruchs und der Datenmanipulation (und und und).  Falsch gesetzte Dateirechte sind in einer chroot Umgebung nur „halb so schlimm“. Nehmen wir z. B. die beliebte

-rw-r--r-- 1 thomas thomas 0 2011-07-15 10:22 config.php

Natürlich kann und muss der Webserver die Datei lesen können, aber der Benutzer Satans101 kann die Datei auch lesen und sein teuflisches Werk damit treiben. Nutzt man chroot, schützt man primär die Benutzer voreinander. Ein Einbruch mit ergattern eines Shell Zugangs und Zugriff auf andere Benutzerdaten,  ist so nicht ohne weiteres möglich (ich erspare mir Sachen wie  how-to-get-shell-acces-in-no-mans-land). Ein hervorragender Weg ist dabei die sftp chroot Umgebung von ssh zu nutzen. Vorteil ist man muss keine extra Software installieren und nutzt die Möglichkeiten von ssh. Ganz kurz sieht das in der /etc/ssh/sshd_config etwa so aus:

AllowGroups ssh-allow sftp-allow
Subsystem sftp internal-sftp
Match group sftp-allow
ChrootDirectory /user/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match

Wichtig dabei ist

chown root:root /user/home/username

Das Userhome muss root gehoeren.
Das ssh-allow ist natuerlich nur Beiwerk, aber sinnig. Dies ist nur eines der Werkzeuge um die Sicherheit zu erhoehen, tools wie chmod g+s, rkhunter, iwatch, aide, tiger, clamav, limits.conf, quota, fail2ban, open_basedir, portchange, diverse selbst geschrieben Skripte usw. helfen dabei auch weiter.

Ganz grob einige Vorteile von croot mit sftp dabei

  • Benutzer sieht Daten anderer Benutzer nicht
  • Benutzer kann keine Prozesse laufen lassen -> Benutzerprozesses fallen sofort auf
  • Geklaute Accounts haben nur einen begrenzten Nutzen für Einbrecher
  • Unerfahrene Benutzer irren nicht durch das gesamte Dateisystem (ja tun sie tatsächlich)

Nachteile

  • sind zu vernachlässigen

Chroot im Zusammenhang mit sftp nutze ich nun seit über 2 Jahren mit mehreren 100 Benutzern und meine Erfahrungen sind durchweg positiv. Der optimale client dabei ist sshfs. Programme wie fireftp, filezilla, sftp und winscp gehen natürlich auch. Empfehlen kann ich auch eine strickte Trennung der Dienste auf unterschiedliche Systeme, aber wem erzähl ich das, weiß man doch alles.

links: OpenSSH SFTP chroot() with ChrootDirectory

Wir speichern mal Deine Daten

Malte Spitz, Mitglied im Bundesvorstand der Grünen, hat die ihm vom Mobilfunkbetreiber T-Mobile ausgehändigten Vorratsdaten in einer interaktiven Karte mit Hilfe des Unternehmens Opendatacity visualisieren und veröffentlichen lassen. Auf Zeit online stehen die Daten außerdem in 35.831 Zeilen einer Google-Kalkulationstabelle bereit.

http://www.heise.de/newsticker/meldung/Vorratsdaten-Sechs-Monate-im-Leben-des-Malte-Spitz-1197178.html
http://www.zeit.de/digital/datenschutz/2011-02/vorratsdaten-malte-spitz

Besonders der generierte Film ist schoen visualisiert.

http://www.zeit.de/datenschutz/malte-spitz-vorratsdaten

 

php shells

Wer Webserver fuer eine groessere Anzahl an Benutzern betreibt, wird wohl oder uebel mit Php Shells konfrontiert werden.
Einen 100% zuverlaessigen Schutz gibt es natuerlich nicht. Ein paar einfache Moeglichkeiten den Schaden in Grenzen zu halten gibt es jedoch:

  • open_basedir Direktive fuer vhosts nutzen
  • Web und File Server trennen, besonders wenn sinnfreier Weise ssh erlaubt ist
  • Beobachten was fuer neue Dateien (auch Besitzerrechte, ggf. nach Mustern grepen) und wann sie angelegt wurden (klingt aufwendiger als es ist)
  • Falls man eine shell findet, zeit nah nach Pattern daraus auf dem Fileserver suchen
  • clamav laufen lassen

Shells gibt es sowohl im Klartext, als auch in gepackter Form.

Also etwas in der Art wie

<? eval(gzinflate(base64_decode('7X1rcxs5kuBnd0T/B7...

oder klassisch etwas wie

$language='ru';
$auth = 0;
$name='r57'; // knchm onk|gnb`rek?  (user login)
$pass='r57'; // o`pnk| onk|gnb`rek? (user password)

Die Dateien werden entweder hochgeladen oder ueber cross-site scripting aufgerufen.

Es gibt eine ganze Reihe solcher Php shells: r57, c99, c100, madshell, small php web shell, nst shell, php bypass shell, sim attacker shell, safe0ver bypass shell….
Klar worauf ich hinaus will? Diese shells existieren in unterschiedlichen Versionen und Anpassungen. Der Funktionsumfang der shells reicht dabei vom einfachen Kommando ausfuehren, bis hin zu irc remote und checks auf bestimmte Sicherheitsluecken und vieles mehr.
Kurz gesagt: ist das System nicht aktuell und man findet eine solche Shell, steigen die Chancen auf eine Kompromittierung des gesamten Systems. Einen local root exploit nachzuladen und auszufuheren ist kein grosser Aufwand.

Was tun wenn der Einbruch festgestellt wurde?
Da gibt es sicherlich eine Reihe von Vorgehensweisen, die empfohlen werden. Als ersten Schritt wuerde ich immer den entsprechenden vhost deaktiveren, die Dateien aber nicht loeschen sondern untersuchen (am besten auf einen anderen System). Sich selbst anschauen was fuer Funktionen die Shell bietet, also ruhig ausprobieren was man damit alles so anstellen kann, das hilft den moeglichen Schaden einzuschaetzen. Natuerlich den Vhost Inhaber informieren. Versuchen mit dem Vhost Administrator herauszufinden wie der Einbruch ueberhaupt moeglich war. Relativ haeufig sind nicht geupdatete CMS Systeme das Einstiegstor. Den Vhost erst wieder online nehmen wenn die Luecke gestopft ist.

Intrusion detection ist ein weites (weites) Feld. Daher beschraenke ich mich mal auf diesen kleinen Beitrag. Das man intrusion detection Systeme und diverse Monitoring tools im Einsatz haben sollte,  ist selbstverstaendlich. Es ist schwierig bei einer grossen Anzahl von Usern den Ueberblick zu behalten, trotzdem sollte man versuchen besonders CMS Systeme im Auge zu behalten und gegebenenfalls auch zentral anzubieten, bzw. upzudaten.