Penetrationstesting

[schoko_hase]

Hi,

mir wurde dieses Forum empfohlen, da hier einige Experten im Bereich Security sein sollen.

Und zwar, habe ich mir eine Penetrationstestumgebung aufgebaut. Ein Suse 10 ungepatcht.
Installiert ist postfix, sshd, proftpd und mysql.

Habe mich dann mal bei securtiyfocus nach exploits umgesehen. Soweit ich weiß ist dies die größte Datenbank, was Schwachstellen auflistet bzw. exploits bietet?

Aber, da ich das system von außen "angreifen" wollte, benötige ich ja remote Exploits. Habe dann mal nach den verschiedenen Produkten gesucht nach deren Versionen gesucht und musste feststellen, das es eigentlich keine bekannten exploits dazu gab.

Um auf meine eigentliche Frage zukommen, bin ich recht der Annahme, das ein naja auch 2 Jahre altes System mit den Standardkomponenten ziemlich sicher ist?

[Peanut]

Ich hab mal kurz gesucht .... gefunden habe ich einige exploits, die Zeit kommt etwa hin, allerdings weiss ich nicht welche Versionen der einzelnen Dienste du benutzt und nochmals werde ich nicht suchen ;-)

Es würde mich erstaunen wenn du ein 2-Jähriges System (ich nehme mal an von CD) installierst und es ohne zu patchen keinerlei Lücken aufweisen würde...

Nur weil du scheinbar nichts findest, heisst das nicht, dass es keine Lücken gibt.

Ausserdem hat das ja nicht so viel mit Penetrationtesting zu tun ... oder?

[Rodnox]

SecurityFocus ist nicht die einzige Seite fuer Exploits.

Fuer den Zeitraum vor 2 Jahren solltest du dir das milw0rm Archiv dursehen. Auch die Pen-Test Listen sollten zumindest Luecken beinhalten. Securitytracker ist ebenso eine DB fuer verwundbare Luecken, gegen die man sich schuetzen sollte.


Und zu deiner annahme: Nein, ein 2 jahre altes system ist nicht "ziemlich sicher". Es gab auch in den letzten 2 Jahren eine Hand voll High Risk Vulnerabilities fuer Suse


Fuer Web Server ist es aber muehsig, sich alte luecken zu suchen und anhand von exploits zu versuchen zugang zu erhalten.

Da eine SQL DB zum beispiel auch daran gebunden ist, wie sie angewendet wird, empfehlen sich Web Security Scanner wie Nikto.

[schoko_hase]

ok ich bedanke mich sehr für die antworten.
Zum Thema Webserver wollt ich gar nicht weiter eingehen, weil das ist dann ja ein Thema für sich, wie z.b. xss oder ähnliches.

Ich werde mir die Datenbanken, die ihr mir genannt habt einmal näher anschauen.

Aber was gehört für euch noch zu einem Penetrationstest?
Ich denke eigentlich jeder der einen Linuxserver Produktiv einsetzt wird diesen annähernd so konfigurieren, das das root kennwort nicht unbedingt root oder r00t ist

Andere Angriffmöglichkeiten, außer das ausnutzen von Schwachstellen bleiben bei einem System doch gar nicht übrig? Ohne einen Benutzernamen + kennwort komm ich nicht auf die maschiene, weder per ssh,noch ftp.

Habe mir auch mal das Buch "penetrationstesting" gekauft und durchgelesen, abgesehen von informationen sammeln steht dort ja recht wenig drin, falls dies jemand kennt.

Wäre dankbar, wenn sich noch jemand zu dem Thema äußern würde, was er bei einem Penetrationstest noch alles untersuchen würde.

Gruß Eure Sarah

[CryptoCrack]

Zitat von schoko_hase

Andere Angriffmöglichkeiten, außer das ausnutzen von Schwachstellen bleiben bei einem System doch gar nicht übrig? Ohne einen Benutzernamen + kennwort komm ich nicht auf die maschiene, weder per ssh,noch ftp.

Ja, das Problem ist nur, dass solche Schwachstellen oft nicht durch Vulnerabilities der installierten Software selbst, sondern durch Unachtsamkeit/Unsorgfaeltigkeit (manchmal sollte man sogar eher "Dummheit" sagen) des Admins entstehen. Das faengt an bei schlecht gewaehlten Passwoertern, geht ueber falsch gesetzte Permissions (auch: "Wieso der beliebte Tipp, einfach alle Files mit 777 zu chmod'en, wenn's irgendwo Probleme mit Permissions gibt, nicht unbedingt so klug ist.", "Warum man nicht bei jeder beliebigen Binary das setuid-Bit schenken sollte, nur damit $user $file damit verarbeiten kann." oder "Weshalb man nicht kurz waehrend der Kaffeepause in der sudoers(5) $user erlaubt $binary mit root-Rechten auszufuehren, damit dieser $job damit erledigen kann."), Fehlkonfiguration von Daemons (bei FTP-Daemons vergessen, den Anon-Login abzuschalten; ein unbeabsichtigt offenes Mail-Relay; 1:1-Konfiguration nach "Anleitung"/"Tutorial", die/das entweder unbrauchbar oder nicht auf den speziellen Anwendungsfall zugeschnitten ist), sonstigen Bequemlichkeitsfehlern ($user fuer die Benutzung von $service einen UNIX-Account mit Passwort anlegen, aber vergessen, die Loginshell auf /sbin/nologin oder /bin/false zu setzen; fuer - selbstverstaendlich, da dort keine wichtigen Daten uebertragen werden, unverschluesseltes - FTP und SSH dasselbe Passwort verwenden und darauf warten, dass jemand tcpdump(8), Wireshark o.ae. anschmeisst) und letztendlich auch veralteter Software - viele Vulnerabilities sind nur deshalb ueberhaupt ausnutzbar, weil der Admin nachlaessig war und die Kiste nicht upgedatet/gepatcht hat.

Ein Server kann nur dann sicher sein, wenn er ordentlich konfiguriert ist (und zwar nicht nach Anleitung, sondern von einem Admin, der Ahnung hat und weiss, was er tut), ebenso ordentlich gewartet wird und der Admin mit vertraulichen/sicherheitsrelevanten Daten bzw. Informationen nicht leichtsinnig umgeht.

[schoko_hase]

ja du hast recht, aber ich denke das solche fehler doch shcon allein durch die distri ausgemerzt werden.

nirgends ist postfix noch standardmäßig als openrelay konfiguriert. anony ftp ist ebenfalls soweit ich weiß überall aus.

gut, möglichkeit wären die schlechten passwörter, aber dafür müsste bei einem system von außen schon ssh erreichbar sein und dies wird ja in der regel durch eine firewall und sei es ein stinknormaler dsl router geblockt, da keine portweiterleitung zum ssh dienst konfiguriert sind, also würde man hier nun auch nicht weiterkommen.

die sache mit den rechten ist ja ganz nett und das passiert mitsicherheit sehr sehr oft, aber selbst das nutzt mir ja erst etwas ,wenn ich auf der kiste bin.

Bzgl. tcpdump geb ich dir natürlich recht, so bekommt man am schnellsten die kennwörter raus, aber sobald der "angriff" von remote erfolgen soll, also aus dem internet, bringt mir tcpdump nichts, weil ich ja nicht im lan bin.
Hier bleibt mir dann sicherlich nur die Möglichkeit, zu versuchen einen Clientrechner zu beschlagnahmen um darüber dann ins Netz zu kommen, bzw. eine mitm zu starten...aber selbst hier wirds schwer, sobald auch nur ansatzweise nen av scanner installiert ist, und dieser ist ja nun doch schon quasi "serienmäßig"

Gruß Eure Sarah

[CryptoCrack]

Zitat von schoko_hase

ja du hast recht, aber ich denke das solche fehler doch shcon allein durch die distri ausgemerzt werden.

Nein, denn sonst wuerden sie nicht passieren. Und solche Dinge passieren oft genug, trust me.

Zitat von schoko_hase

nirgends ist postfix noch standardmäßig als openrelay konfiguriert.

Frueher war das aber Default bei vielen Mailservern und auch heute gibt es noch Admins, die das auf die Reihe bekommen (auch wenn ich zugeben muss, dass das Beispiel hier vielleicht nicht das treffendste war/ist).

Zitat von schoko_hase

anony ftp ist ebenfalls soweit ich weiß überall aus.

What? Andersrum, Anonymous-Accounts sind (zumindest mit Leserechten) per Default meistens aktiviert - soll aber auch vorkommen, dass der "aus Versehen" uploaden kann.

See vsftpd:

       anonymous_enable
              Controls whether anonymous logins are permitted  or
              not.  If enabled, both the usernames ftp and anony-
              mous are recognised as anonymous logins.

              Default: YES

See Arch Linux's Default-proftpd-Config:

blizzard% sudo pacman -S --noconfirm proftpd > /dev/null && grep -B2 '^<Anonymous' /etc/proftpd.conf
# A basic anonymous configuration, no upload directories.  If you do not
# want anonymous users, simply delete this entire <Anonymous> section.
<Anonymous ~ftp>

See pure-ftpd, bei dem's nicht einmal eine Option gibt, um Anonymous-Accounts zu aktivieren, sondern eine, um sie zu deaktivieren:

blizzard% sudo pacman -S --noconfirm pure-ftpd > /dev/null && grep -B2 ^NoAnonymous /etc/pure-ftpd.conf 
# Disallow anonymous connections. Only allow authenticated users.

NoAnonymous                 no

Haengt natuerlich auch teilweise von der verwendeten Distri ab, manche Distris ueberschreiben die Werte per Default, um das zu deaktivieren und beim pure-ftpd-Package aus den stable-Repos von Debian is der Anonymous-Account z.B. standardmaessig auskommentiert.

Zitat von schoko_hase

gut, möglichkeit wären die schlechten passwörter, aber dafür müsste bei einem system von außen schon ssh erreichbar sein und dies wird ja in der regel durch eine firewall und sei es ein stinknormaler dsl router geblockt, da keine portweiterleitung zum ssh dienst konfiguriert sind, also würde man hier nun auch nicht weiterkommen.

Von was reden wir denn ueberhaupt? Von einem ueber's Internet erreichbaren Server, von einem Server im Firmennetz oder von einer kleinen Workstation im Heimnetz hinter einem "DSL-Router"? Angriffe koennen auch "von innen" erfolgen. Entweder von "boesen Mitarbeitern" oder von solchen, die zum Beispiel durch Social Engineering dazu bewegt werden.

Zitat von schoko_hase

die sache mit den rechten ist ja ganz nett und das passiert mitsicherheit sehr sehr oft, aber selbst das nutzt mir ja erst etwas ,wenn ich auf der kiste bin.

Auf die Kiste kommt man recht schnell. Dazu reicht manchmal 'ne Kombination aus FTP-Upload und PHP (was in der Praxis auch recht haeufig vorkommt). Ausserdem - kann man immer allen lokalen Benutzern voll vertrauen? Wenn ja, warum gibt es dann ueberhaupt noch Mehrbenutzersysteme? Sehr viele Angriffe laufen btw so ab, dass zunaechst via Remote-Exploit Zugriff auf die Kiste und anschliessend mit lokalem root-Exploit root-Rechte erlangt werden.

Zitat von schoko_hase

Bzgl. tcpdump geb ich dir natürlich recht, so bekommt man am schnellsten die kennwörter raus, aber sobald der "angriff" von remote erfolgen soll, also aus dem internet, bringt mir tcpdump nichts, weil ich ja nicht im lan bin.

Auch "im Internet" kann man tcpdump einsetzten, nur leider nur an sehr speziellen Punkten, wenn man etwas sinnvolles mitlesen will. Es kann aber auch ein Angriff vom selben Subnetz aus oder - wenn der Admin dumm genug ist - vom selben Host aus erfolgen, siehe [1].

Zitat von schoko_hase

Hier bleibt mir dann sicherlich nur die Möglichkeit, zu versuchen einen Clientrechner zu beschlagnahmen um darüber dann ins Netz zu kommen, bzw. eine mitm zu starten...aber selbst hier wirds schwer, sobald auch nur ansatzweise nen av scanner installiert ist, und dieser ist ja nun doch schon quasi "serienmäßig"

Bei welchem OS ist Antiviren-Software standardmaessig installiert? Ich hab' auf keiner einzigen Kiste hier einen. Und ich kann dir leider nicht ganz folgen in diesem Punkt - geht es bei der ganzen Sache um ein Firmennetz mit lauter ganz Mitarbeitern, die immer, immer, immer ganz brav sind und denen as Weihnachtsgeld beim Versuch, einen der Server zu hacken, gestrichen wird? :> Es soll uebrigens auch schon dazu gekommen sein, dass selbst grosse Firmennetzwerke mit Wuermern infiziert wurden, obowhl die eine riesen IT-Abteilung, eine tolle Firewall und ueberall Antivirensoftware installiert hatten.

[1] strcat's Blog - Wie man sich mit sudo(8) gezielt in den Fuß schiessen kann

[eax]

Also was ich hier gelesen habe ueber firewalls und Av-scanner diese dann als "Allheilmittel" eingestufft wurden helfen vlt. gegen standart Viren und Wuermer. Sobald du es aber mit einem geplanten Angriff zu tun hast, helfen diese fast garnicht mehr... es erschwert dem Angreifer vlt. die Arbeit.

Er braucht dazu nur ein http tunnel benutzen und seine daten verschluesseln. Schon ist die Firewall und der Av-scanner umgangen. Eine gute meoglichkeit sind angriffen aufzuspeuren sind IDS. Wenn du direkt aber einen Angriff bekaempfen willst muesstest du zu einem IPS greifen.

http://de.wikipedia.org/wiki/Intrusion_Detection_System
http://de.wikipedia.org/wiki/Intrusi...vention_System

[schoko_hase]

Von was reden wir denn ueberhaupt? Von einem ueber's Internet erreichbaren Server, von einem Server im Firmennetz oder von einer kleinen Workstation im Heimnetz hinter einem "DSL-Router"? Angriffe koennen auch "von innen" erfolgen. Entweder von "boesen Mitarbeitern" oder von solchen, die zum Beispiel durch Social Engineering dazu bewegt werden.

Also ich gehe von einem Server aus, der im Internet steht.

Das ein Mitarbeiterrechner deutlich weniger geschützt ist bzw. beachtung geschenkt wird, ist uns allen ja sicherlich klar. Das ich in einem internen Lan sehr schnell an das Kennwort des Admins mittels Mitm kommen kann, ist denke ich mal allen bewusst.

Der Blogeintrag von strcat bzgl. sudo ist wirklich lustig zu lesen, aber da hat definitiv recht, das das grob fahrlässig war.

Aber wirklich interessant wird das doch Thema Penetration, wenn es um einen Rechner im Internet, der dann noch hinter einer Firewall steht, so wie es bei all unseren Kunden der Fall ist. Kurz zu mir, ich arbeite als Fachinformatikerin in einem Systemhaus.
Wir haben bei allen Kunden Astaro Firewalls, welche dann entsprechend Ports zu den Servern weiterleiten, wo dann Linux oder Win Maschienen stehen.

Und ich kann derzeit leiden keinen weg finden auch nur ansatzweise eines dieser Systeme anzugreifen. Daher der Versuchsaufbau mit den 2 Linuxkiste. Um mich mehr mit der Thematik auseinander zu setzen.

[eax]

Also verstehe ich das richtig du willst die Systeme deiner Kunden auf ihre Sicherheit testen. Das wichtigeste an einem Pentest ist soviel Informationen zu bekommen wie nur meoglich. Die du dann auf Schwachstellen untersuchen kannst. Daher muessten wir schon mehr ueber die Server wissen.

Falls du dich noch ein wenig zu dem Thema informieren moechtest hier eine ausgabe von Hakin9.

http://hakin9.org/app/files/download...&portal_id=108

[Peanut]

Läuft auf dem Kundenserver evtl. auch ein Webserver? Dann müsste man evtl. noch vorhandene Web-Applikationen auf ihre Sicherheit überprüfen ;-)

[schoko_hase]

Hey,
also ich möcht nicht gleich morgen auf meine kundennetze los. Das das nicht klappt weiß ich. Daher ja auch mein versuchsaufbau wie oben beschrieben. Nur leider scheitere ich dabei ja schon kläglich, weil ich kein Lücken bzw exploits gefunde

nein einen Webserver habe ich expliziet ausgelassen, da das allein ein Riesen thema ist

[Rodnox]

Zitat von schoko_hase

Nur leider scheitere ich dabei ja schon kläglich, weil ich kein Lücken bzw exploits gefunde

Das liegt entweder daran, dass der server sicher ist oder das sich dein Erfahrungsschatz in Grenzen haelt.

Hacking funktioniert nicht nach Lehrbuch. Es gibt kein 1 x 1 des Cybereinbruchs. Es kommt viel darauf an, was du aus vergangenen Fehlern schon gelernt hast, ob du die entwicklung eines systems beobahtet hast und daher weisst welche Schwachstellen sich in frueheren Versionen "etabliert" haben, viel haengt davon ab ob du kleinere Ablaeufe automatisieren kannst, ob du Datenbankstrukturen verstehst und von daher Luecken findest, ob du in der Lage bist pakete abzufangen, neuere techniken und systeme sind immer schwerer zu penetrieren und erfordern daher auch schon fast entwickler kenntnisse (Stichwort LDAP Injection),etc ...

Hacking ist ein bischen wie Jagen. Der Hase laeufft nicht immer in die selbe Richtung. Es ist nichtmal immer ein Hase den du jagst. Du musst dich anpassen koennen und das Zielgebiet erfordert umfassende Kenntniss.

Deshalb ja Informationen sammeln. Die Systemsicherheit steht und faellt mit der Intelligenz des Angreifers. Du musst lernen ... viel lernen ...

Einige PDF's zum Thema "Pen Testing"

Eventuell ist es dir ja so wichtig, das du auch finanziell etwas aufwenden moechtest. Da Pen Testing Training in Deutschland aber sehr schwierig ist, weil die GEsetzgebung das leider etwas eingeschraenkt hat, bieten sich Online Security Training Portale an.

[dexcs]

Ergänzend zu rodnox: Gute Schulungen bietet auch http://syss.de/ aus Tübingen an. Herr Schreiber ist mir ein paar mal persönlich über den Weg gelaufen und hat echt Ahnung auf dem Gebiet, wenn auch seine Beiträge in Funk und TV manchmal etwas "laienhaft" rüberkommen, aber sonst würde es glaub keiner Blicken ;-)