Großer Bornhorster See
Haaren zur blauen Stunde
Oldenburger Classic Days 2017 – City Grand-Prix
Unbricking eines TL-WR710N V2
Für ein Projekt brauchte ich auf einem TP-LINK WR710N unbedingt OpenVPN. Normalerweise sind die kleinen Router dafür gut geeignet. Leider habe ich die zweite Hardware-Revision V2 erwischt. Hauptunterschied zum Vorgänger ist der halbierte Flash. Somit hat man beim aktuellen OpenWRT Image Chaos Calmer 15.05 keine Chance, OpenVPN nachträglich zu installieren. Ein erster Versuch das Image eigenständig zu bauen, erzeugte leider einen Ziegelstein und der Router war nutzlos.
Also habe ich mir kurzer Hand einen UART-Adapter für USB mit CP2102 Chipsatz besorgt. Wichtig ist hierbei der Hinweis auf UART, denn ein RS232 Adapter funktioniert nicht. Die serielle Schnittstelle wird wie folgt gelötet:
| Platine | Atheros AR9331 Pinout | UART-Adapter PIN |
| TP_IN | TXD | RXD |
| TP_OUT | RXD | TXD |
| GND | GND | GND |
Die Anschlüsse TP_IN und TP_OUT sind auf dem Bild gut zu erkennen. GND findet man unterhalb der Antenne. Alternativ kann man auch die Erdung beim USB-Port verwenden. 3,3V oder 5V am UART-Adapter werden nicht benötigt. Der AR9331 liefert bereits die nötige Spannung und verträgt keine 5V.
Anschließend kann man mit einem Terminal-Programm seiner Wahl die serielle Konsole starten. Wichtig ist die Baud-Rate von 115200 bei 8N1. Hard- und Software Flow Control sind deaktiviert.
screen /dev/ttyUSB0 115200,-parenb,-cstopb,cs8
Anschließend direkt nach dem Einschalten den Bootvorgang mit „tpl“ unterbrechen. Der Bootvorgang sieht zunächst so aus:
U-Boot 1.1.4 (Jan 14 2014 - 15:03:18) AP121 (ar9330) U-boot DRAM: 32 MB led turning on for 1s... id read 0x100000ff flash size 4194304, sector count = 64 Flash: 4 MB Using default environment In: serial Out: serial Err: serial Net: ag7240_enet_initialize... No valid address in Flash. Using fixed address No valid address in Flash. Using fixed address : cfg1 0x5 cfg2 0x7114 eth0: 00:03:7f:09:0b:ad ag7240_phy_setup eth0 up : cfg1 0xf cfg2 0x7214 eth1: 00:03:7f:09:0b:ad athrs26_reg_init_lan ATHRS26: resetting s26 ATHRS26: s26 reset done ag7240_phy_setup eth1 up eth0, eth1 Autobooting in 1 seconds
Für die Wiederherstellung wird ein TFTP Server benötigt. Dort wird das Image „openwrt-ar71xx-generic-tl-wr710n-v2-squashfs-factory.bin“ abgelegt. Der TFTP-Server muss über die IP 192.168.1.100 erreichbar sein. Der Boot-Loader verwendet die IP 192.168.1.111.
Der uboot-Bootloader ist an der Eingabezeile mit „hornet>“ erkennbar. Für die V2 muss der Speicherbereich angepasst werden, in den das Image geschrieben wird. Bei 4MB Modellen muss das Image ab 0x3c0000 geschrieben werden. Zusammenfassend werden diese Befehle verwendet:
tftpboot 0x81000000 openwrt-ar71xx-generic-tl-wr710n-v2-squashfs-factory.bin erase 0x9f020000 +0x3c0000 cp.b 0x81000000 0x9f020000 0x3c0000 bootm 9f020000
Und im uboot sieht es dann so aus:
hornet> tftpboot 0x81000000 openwrt-ar71xx-generic-tl-wr710n-v2-squashfs-factory.bin dup 1 speed 1000 Using eth1 device TFTP from server 192.168.1.100; our IP address is 192.168.1.111 Filename 'openwrt-ar71xx-generic-tl-wr710n-v2-squashfs-factory.bin'. Load address: 0x81000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ###################################################### done Bytes transferred = 3932160 (3c0000 hex) hornet> erase 0x9f020000 +0x3c0000 First 0x2 last 0x3d sector size 0x10000 61 Erased 60 sectors hornet> cp.b 0x81000000 0x9f020000 0x3c0000 Copy to Flash... write addr: 9f020000 done hornet> bootm 9f020000
Mit dem Befehl „bootm“ wird das System gestartet und nach kurzer Zeit sollte alles wieder in Ordnung sein.
Eine Auszeit auf der Insel
Die vorherigen Beiträge hier waren doch sehr technisch und so möchte ich dieses mal ein paar Schnappschüsse teilen. Meine bessere Hälfte und ich haben dieses Jahr den 1. Mai genutzt, um nach einer stressigen Phase uns eine Auszeit zu gönnen.
Wir sind früh morgens aufgebrochen, damit wir einer der ersten auf der Insel Spiekeroog waren. Das Wetter war zwar noch recht kühl, dafür hat uns die Sonne den Tag versüßt – Sonnenbrand inklusive.
Viel Spaß mit den Bildern!
Shellshock Proof of Concept
Nach Heartbleed ist aktuell der Bug Shellshock (CVE-2014-6271) wohl eine der gravierendsten Sicherheitslücken seit langer Zeit. Dadurch sind unter anderem zahlreiche Apache-Webserver auf Linux-Systemen betroffen, die durch das aktivierte Modul mod_cgi Scripte ausführen.
Hierzu gehören unter anderem Shell-Skripte. Hinzu kommt, das dieser Bug seit gut 25 Jahren in der Bash aktiv war und seit jeher Systeme theoretisch kompromittiert werden konnten.
Interessant ist auch der Ansatz von Geoff Walton den er in seinem Blog-Beitrag beschreibt. Die Lücke wird per DHCP-Option vom DHCP-Server an den Client übergeben und somit ist es möglich, auf einem DHCP-Client aus der Ferne Befehle auszuführen.
Absicherung von ownCloud mit Hilfe von fail2ban
Da die Grundinstallation von ownCloud in meinen Augen intransparent hinsichtlich Sicherheit ist, kam mir der Gedanke, fail2ban hierfür einzusetzen. Bei der Recherche habe ich mehrere Lösungsansätze gefunden, die aber nicht so richtig funktionieren wollten.
Ziel soll es sein, Brute-Force Attacken zu verhindern. Hierzu sei dank des Hinweises von Lutz Donnerhacke zu erwähnen, dass diese Lösung eine Brute-Force Attacke nicht in Gänze verhindert, sonder lediglich als Präventionsmaßnahme dient.
„Absicherung von ownCloud mit Hilfe von fail2ban“ weiterlesen
Backup von MySQL-Datenbanken
Bisher war ich ein großer Fan des Backup-Scripts AutoMySQLBackup. Es ist einfach zu installieren und macht die Datensicherung von MySQL-Datenbanken sehr einfach. Dummerweise bietet es aber keine Möglichkeit, die Retention-Time anzupassen. Mark Grennan hat zu diesem Zweck das Script angepasst. Allerdings waren einige Änderung notwendig, damit es sauber funktioniert:
- Auslagerung der Konfigurations-Parameter auf Debian-Standard
- Anpassung des Konfigurations-Pfad zu /etc/default/automysqlbackup
- Änderung der mysqldump Optionen, denn master-data=2 wird nicht benötigt und erfordert Binlogging
- Einfügen einer Überprüfung, ob USERNAME und PASSWORD gesetzt sind, da ich ~/.my.cnf hierfür benutze
Wer diese Änderung nutzen will, darf gerne den Patch und die Default-Config automysqlbackup verwenden. Zur Vervollständigung als Kurzanleitung:
Auch Clients sind von Heartbleed betroffen!
Bei den Diskussionen über Heartbleed fällt häufig die Tatsache unter dem Tisch, das nicht nur Server betroffen sind, sondern auch bei Clients das Exploit verwendet werden kann, um Remote 64 KiB aus dem Speicher zu lesen. Hinzu kommt die Erkenntnis, das hierfür nicht mal ein Zertifikat bei der Gegenstelle vorhanden sein muss, da Heartbeats in betroffenen OpenSSL Versionen bereits vor dem Austausch von Zertifikaten oder Schlüsseln akzeptiert werden.
Die Vorgehensweise ist recht simpel:
- Auf das ClientHello mit der TLS Version und der Cipher Suite warten
- Senden des ServerHello mit der gleichen TLS Version und Cipher Suite (um Handshake Fehler zu vermeiden)
- Ab diesem Zeitpunkt können vom vermeintlichen Server beliebig viele Heartbeats gesendet werden
Für gewöhnliche Web-Anwendungen ist dieses Proof of Concept uninteressant, dennoch bietet es bei clientseitigen Zertifikaten ein Angriffsszenario an – beispielsweise bei OpenVPN Clients ist hiermit eine Man in the Middle Attacke denkbar, um den privaten Schlüssel eines Clients zu erbeuten.
Zur Demonstration hat Peter Wu hierzu das Proof of Concept pacemaker veröffentlicht und stelle die Ergebnisse gerne vor.
Bin ich gegenüber den Heartbleed-Bug verwundbar?
Zur Zeit wird viel über den Heartbleed-Bug (CVE-2014-0160) in OpenSSL diskutiert. Betroffen sind die Versionen 1.0.1 bis 1.0.1f. Scheinbar ist dieser Bug einer der gravierendsten seit langem. Ein Angreifer kann über das Internet 64KB des Arbeitsspeichers eines entfernten Systems auslesen, dessen Verbindung mit der betroffenen OpenSSL Version abgesichert ist.
So kann zunächst der private Key des Systems ausgelesen werden, womit es möglich wird, jeglichen Datenverkehr zu entschlüsseln. So können laufende Verbindungen ausgelesen werden, aber auch Datenverkehr, der in der Vergangenheit abgefangen wurde. Passwörter oder weitere sensible Daten können so ohne Probleme erspäht werden.
Ich habe hier eine kurze Anleitung zusammengeschrieben, mit dessen Hilfe ein Server auf diese Verwundbarkeit überprüft werden kann. Basis ist hierbei das Script von Filippo Valsorda.
„Bin ich gegenüber den Heartbleed-Bug verwundbar?“ weiterlesen