31c3 - Livestream vom 31. Chaos Communicaton Congress

Wie jedes Jahr nach den Weihnachtsfeiertagen findet auch 2014 der Chaos Communicaton Congress mit interessanten Beiträgen im Hamburg statt. Dieses Mal zum 31. Mal auf 4 Bühnen und natürlich einem Livestream. Dieser ist unter streaming.media.ccc.de erreichbar und läuft (bis jetzt) flüssig.

ccc

Eine Empfehlung für den heutigen Tag ist sicherlich der Beitrag von Tobias Engel zur der SS7 Schwachstelle im UMTS Netz. Diese beginnt bereits in wenigen Minuten. Dem kompletten Fahrplan für die nächsten Tage könnt ihr weitere interessante Beiträge entnehmen.

Sollte die Sprachbarriere für den ein oder anderen Nutzer ein Problem darstellen, so kann teilweise zwischen Deutsch und Englisch gewechselt werden. Über den Webplayer sollte das kein Problem darstellen, weitere Infos gibt es hier. Es wird jedoch der VLC Player für ein einwandfreies Streaming empfohlen.

Routerpwn Exploit Sammlung - Prüfen ob der eigene Router noch sicher ist

Das Jahr 2014 war nicht nur das Jahr der Datendiebstähle, sondern auch der massiven Router Schwachstellen. Bekanntestes Beispiel war sicherlich die offene Lücke in AVM Geräten, die es Fremden erlaubte mal eine Runde zu telefonieren.

Neben AVM waren natürlich auch andere Hersteller, wie D-Link, Belkin oder TP-Link betroffen. Neben Webinterfaces mit Internetzugriff oder Hintertüren zum Auslesen des Administratorpassworts blieb fast kein Auge trocken.

Höchste Zeit den eigenen Router auf eine aktuelle Firmware zu aktualisieren.

Routerpwn

Die Webseite Routerpwn.com bietet eine gute Anlaufstelle, wenn es darum geht den eigenen Router auf Schwachstellen zu prüfen. Die Seite listet ca. 40 Routerhersteller und deren Produkte inklusive der vorhandenen, bzw. bekannten Sicherheitslücken auf.

routerpwn

Die Seite selbst kann als Linksliste angesehen werden, denn sie verweist im Detailbereich einer Schwachstelle auf die jeweilige Quelle. Hierbei handelt es sich meist um Seiten wie 1337day, Exploit-DB oder andere Webseiten, die sich mit dieser Thematik auseinandersetzen.

Auf der jeweiligen Quellseite wird neben den betroffenen Produkten und deren Firmware, ausführlich beschrieben, wie sich die Schwachstelle äußert und welche Gefahren bestehen.

Hier ein Beispiel

============ Vulnerable Firmware Releases - DIR-XXX: ============

Firmware Version : 1.05 , Fri 26 Nov 2010

============ Vulnerability Overview: ============

  • OS Command Injection (1)

The vulnerability is caused by missing input validation in the set/runtime/diagnostic/pingIp and the exeshell parameter and can be exploited to inject and execute arbitrary shell commands.
It is possible to start a telnetd to compromise the device. You need credentials for the webinterface.

  • For changing the current password there is no request to the current password (2)

With this vulnerability an attacker is able to change the current password without knowing it. The attacker needs access to an authenticated browser.

  • CSRF for changing the password without knowing the current one and the attacker is able to activate the remote management (3):
http://Target-IP/tools_admin.php?ACTION_POST=1&apply=Save+Settings&xxxxxx
  • Insecure Cryptographic Storage (4):

There is no password hashing implemented and so it is saved in plain text on the system. You will find other ways to get access to it.

Eine aktuelle Software auf dem eigenen Router hat also durchaus seine Berechtigung, denn das Gerät stellt immerhin den Zugang zu allen anderen Geräten im Heimnetzwerk bereit.

Linux Script - Selbstsigniertes SSL Zertifikat mit SHA256 erstellen und ausgeben

Anfang des Jahres hatte ich euch ein Skript bereitgestellt, welches selbst signierte Zertifikate generiert (siehe Artikel).

Nicht erst seit gestern ist es jedoch sinnvoll auf SHA2 umzustellen. Denn das alte SHA1 gilt seit einiger Zeit als unsicher. 

Übersicht SHA Funktionen

uebersicht_sha

Für euch heißt dies in Zukunft bei der Zertifikatsgenerierung auf SHA2 zu achten.

Selbstsigniertes SSL Zertifikat mit SHA256 erstellen

Im Prinzip muss der alte Befehl nur um einen weiteren Schlüssel "SHA256" oder "SHA512" ergänzt werden.

Unten seht ihr den Befehl, der eine privaten Serverschlüssel mit Zertifikatsanfrage erstellt und im gleichen Zug selbst signiert.

sudo openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:4096 -keyout server_256.key -out server_256.crt

Generating a 4096 bit RSA private key

...........................++

......................................................................++

writing new private key to 'server_256.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:DE

State or Province Name (full name) [Some-State]:NRW

Locality Name (eg, city) []:ITrig

Organization Name (eg, company) [Internet Widgits Pty Ltd]:ITrig

Organizational Unit Name (eg, section) []:Itrig

Common Name (eg, YOUR name) []:itrig.de

Email Address []:

Zertifikat auf SHA2 überprüfen

Natürlich lassen sich vorhandene oder soeben erzeugte Schlüssel auch auf ihren Inhalt überprüfen. In diesem Fall interessiert uns der SHA Wert.

sudo openssl x509 -noout -text -in server_256.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            fc:f8:7d:d9:cd:f7:e7:b5

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=DE, ST=NRW, L=ITrig, O=ITrig, OU=Itrig, CN=itrig.de

        Validity

            Not Before: Dec 18 13:20:41 2014 GMT

border: none; padding: 0px;">

            Not After : Dec 17 13:20:41 2019 GMT

Damit ihr euch die Eingaben alle sparen könnt, hab ich das Script auf SHA256 angepasst, zusätzlich werden alle Daten am Ende zur Kontrolle ausgegeben.

SHA 256 Skript

Ubuntu - PostgreSQL Migration - Update eines 8.x Datenbank Servers auf 9.x

Nicht nur ein System im Allgemeinen sollte auf Stand gehalten werden, sondern auch die dort installierten Pakete. Neben Web,- oder Mailservern sind auf vielen Rechnern auch Datenbankserver installiert.

Heute soll es genau um diese gehen. Die Aufgabe ist es, einen PostgreSQL Datenbankserver 8.x auf 9.x zu aktualisieren. 

Vorgehensweise Update

Ein Update des installierten DB Servers kann von Hand vorgenommen werden. Hierzu müssen lediglich die aktuelleren Pakete installiert werden.

sudo apt-get install postgresql-9.x

Bei einigen Nutzern geschieht dieses jedoch von ganz alleine, indem sie beispielsweise ihre Ubuntu Version  von 11.04 auf 11.11 oder von 10.04. auf 12.04, usw. aktualisieren.

Nach einem Distributions Update laufen somit zwei Instanzen (z.B. 8.x und 9.x) auf einem Server, diese sollten zu einer aktuellen zusammengefasst werden.

postgresql

Migration PostgreSQL Server von 8.x auf 9.x

Als erster Schritt wird ein Backup der vorhandenen Datenbank gemacht.

sudo pg_dump -U user -W > /home/user/db_backup

Danach kann mit der Migration begonnen werden, diese muss als Benutzer "postgres" durchgeführt werden. (Der Nutzer sollte genügend Rechte besitzen, um den DB Server zu beenden oder zu starten).

su postgres

pg_dropcluster --stop 9.x main

pg_upgradecluster 8.x main

Stopping old cluster...

Disabling connections to the old cluster during upgrade...

Restarting old cluster with restricted connections...

Creating new cluster (configuration: /etc/postgresql/9.x/main, data: /var/lib/postgresql/9.x/main)...

Moving configuration file /var/lib/postgresql/9.x/main/postgresql.conf to /etc/postgresql/9.x/main...

Moving configuration file /var/lib/postgresql/9.x/main/pg_hba.conf to /etc/postgresql/9.x/main...

Moving configuration file /var/lib/postgresql/9.x/main/pg_ident.conf to /etc/postgresql/9.x/main...

Configuring postgresql.conf to use port 5433...

Disabling connections to the new cluster during upgrade...

Roles, databases, schemas, ACLs...

Fixing hardcoded library paths for stored procedures...

Upgrading database postgres...

Analyzing database postgres...

Re-enabling connections to the old cluster...

Re-enabling connections to the new cluster...

Copying old configuration files...

Copying old start.conf...

Copying old pg_ctl.conf...

Stopping target cluster...

Stopping old cluster...

Disabling automatic startup of old cluster...

Configuring old cluster to use a different port (5433)...

Starting target cluster on the original port...
 

Nach einer erfolgreichen Migration kann der Datenbank Server neu gestartet werden. Erfolgt dies ohne Fehler können die alten DB Server Pakete entfernt werden.

sudo service postgresql restart

     Restarting PostgreSQL 9.x database server
sudo apt-get remove postgresql-8.x

Nun ist der Datenbank Server mit allen vorhandenen Datenbanken auf einem aktuellen Stand.

Fehlersuche

Klar kann es auch bei dieser Migration zu Fehlern kommen. So kann es vorkommen, dass das alte DB Paket bereits entfernt wurde. Diese muss dann einfach noch einmal installiert werden, um eine Migration durchzuführen.

sudo apt-get install postgresql-8x

Der neue Server kann nach der Migration manchmal nicht starten und wirft folgenden Fehler:

The PostgreSQL server failed to start. Please check the log output:

CET FATAL:  could not create shared memory segment: Das Argument ist ungültig

CET DETAIL:  Failed system call was shmget(key=543...1, size=348...., 03600).

CET HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 34881536 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

        If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.

        The PostgreSQL documentation contains more information about shared memory configuration.

Error: Could not start target cluster; please check configuration and log files

Hier genügt es die Konfiguration des neuen Servers anzupassen.

sudo /etc/postgresql/9.x/main/postgresql.conf

max_connections = 10

oder

shared_buffers = 50MB

Spätestens nach dem Beheben dieser Fehler sollte der PostgreSQL Server 9.x ohne Probleme starten

sudo service postgresql start