Kategorie: IT-Security (Seite 8 von 15)

Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.

Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!

Oh ja, die abuse Mail:

Sehr geehrte Damen und Herren,
 
 ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst
 gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch
 von Daten.
 
 Das Unternehmen Nextcloud GmbH hat offen aus dem Internet
 erreichbare Installationen von ownCloud und Nextcloud geprft.
 Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit
 veralteten Software-Versionen laufen, welche verschiedene
 Sicherheitslcken aufweisen.
 
 Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem
 unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen.
 Dabei knnen die Angreifer ggf. sensible Informationen wie z.B.
 persnliche Dokumente, Fotos oder Kundendaten von Unternehmen
 aussphen und diese anschlieend im Internet verffentlichen oder
 fr kriminelle Zwecke wie Erpressungen nutzen.
 Andere Schwachstellen ermglichen Angreifern die Ausfhrung
 beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf.
 zu einer vollstndigen Kompromittierung des Systems und dessen
 Missbrauch fr weitere kriminelle Aktivitten fhren.
 
 Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen
 zur Untersttzung bei der Benachrichtigung betroffener Server-
 Betreiber bereitgestellt.
 
 Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in
 Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann
 die verwundbare Cloud-Installation identifiziert wurde.
 Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine
 eindeutige ID (UUID) angegeben.
 
 Die Nextcloud GmbH stellt unter folgender URL detaillierte
 Informationen zu den bei der jeweiligen Cloud-Instanz erkannten
 Schwachstellen und deren Behebung zur Verfgung:
 https://scan.nextcloud.com/results/[UUID]
 
 Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz
 angegebene UUID ersetzt werden. Beispiel:
 https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678
 
 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
 Aktualisierung der Cloud-Installationen auf den betroffenen Systemen
 zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle
 auf den betroffenen Systemen identifizierten Schwachstellen stehen
 entsprechende Sicherheitsupdates der Hersteller zur Verfgung.
 
 Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen
 wenden Sie sich bitte direkt an die Nextcloud GmbH unter
 <cloud-security-scan@nextcloud.com>.
 
 
 Diese E-Mail ist mittels PGP digital signiert.
 Informationen zu dem verwendeten Schlssel finden Sie unter
 <https://reports.cert-bund.de>.
 
 Bitte beachten Sie:
 Dies ist eine automatisch generierte Nachricht.
 An die Absenderadresse kann nicht geantwortet werden.
 Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte
 unter Beibehaltung der Ticketnummer in der Betreffzeile an
 <certbund@bsi.bund.de>.
 
 ======================================================================
 
 Betroffene Systeme in Ihrem Netzbereich:
 
 Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname
  12345 | 1.2.3.4    | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high       | 80     | cloud.domain.de
  12345 | 1.2.3.5    | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium     | 80     | cloud.wurst.com
  12345 | 1.2.3.6    | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low        | 80     | cloud.alalaa.de 
  12345 | 1.2.3.7    | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high       | 443    | cloud.butani.cn
  12345 | 1.2.3.8    | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high       | 80     | cloud.bima.org
  12345 | 1.2.3.9    | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high       | 80     | cloud.2083a.net
  12345 | 1.2.3.10   | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low        | 443    | cloud.lutzola.nl
  12345 | 1.2.3.11   | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high       | 80     | cloud.weglaa.wu
  12345 | 1.2.3.12   | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium     | 80     | cloud.breck.aa
  [.....]

 
 Mit freundlichen Gren / Kind regards
 Team CERT-Bund
 
 Bundesamt fr Sicherheit in der Informationstechnik (BSI)
 Federal Office for Information Security
 Referat CK22 - CERT-Bund
 Godesberger Allee 185-189, D-53175 Bonn, Germany

Da kommt doch heute folgende E-Mail bei mir an:

Hi,
mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für
munin.kernel-error.com
kaputt ist.

Gruß
Andreas

Tja und? Ja nix… Recht hat der Mann *kopfschüttel* Da habe ich wohl vergessen das zu aktualisieren, als ich das Zertifikat geändert habe: EC 521 bits / SHA256withRSA – Elliptic Curve mit openssl für den Apache

Dank an Andreas! Ach ja, warum ist es nur ihm aufgefallen?!?

Heute möchte ich einmal ein Zertifikat für meinen munin erstellen. Als Test möchte ich einmal ein Zertifikat mit Elliptischen Kurven im Schlüssel probieren. Dieses soll natürlich ebenfalls von StartSSL signiert werden.

Die openssl Befehle sind wie immer nicht weiter besonders….

Schlüssel erstellen:

$ openssl ecparam -out http.key -name secp521r1 -genkey

CSR erstellen:

$ openssl req -new -sha256 -key http.key -nodes -out http.csr

Den Inhalt des CSRs ausgeben und der CA (StartSSL) zum signieren geben, sowie das signierte Zertifikat in die Datei http.crt gießen:

$ cat http.csr 
$ vi http.crt

Alles im PEM-File zusammenführen:

$ cat http.key http.crt > http.pem

Als guten Abschluss noch ein paar Diffie Hellman einwerfen (wenn auch etwas unnötig):

$ openssl gendh 4096 >> http.pem

Fertig ist das Zertifikat! Alles noch wie bekannt in den Apachen werfen und zur Sicherheit einmal Qualys auf die Seite loslassen:

https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com

Damit habe ich also nun ein EC 521 bits / SHA256withRSA Zertifikat. Tja, in meinem Firefox sieht alles aus wie immer. Gut, der Microsoft Rempel schlägt wie so oft hart auf aber ich nutze die Seite eh nie mit dem IE ;-P

Was meint ihr?

Hallo zusammen,

meim Jabber-Server hat gerade ein neues Zertifikat bekommen.

SHA1-Alt:
C0:98:90:B0:DB:CA:02:3B:96:E0:8A:B7:6F:7A:08:FE:3D:5F:E7:A8
SHA1-Neu:
6B:5C:97:AE:C4:54:79:65:16:F7:F2:64:B4:3B:1C:4B:57:FC:B0:3F

Viel Spaß

Ich habe ja beruflich ebenfalls mit der Betreuung von Systemen in China zu tun. Die Probleme mit der „great wall of china“ sind mir also bekannt. Onlineüberwachung ist hier also sehr deutlich vertreten, sobald man etwas Crypto einsetzte, wird die Verbindung gleich so schlecht, langsam und instabil, dass es keinen Spaß mehr macht sie zu nutzen. Wenn es überhaupt zu einer Verbindung kommt!

Was mir aber jetzt geschickt wurde ist schon hart 🙂 „sicheres onlinebanking in China“ oder so ähnlich! Erlaubt ist, was geknackt werden kann. *kopfschüttel*. 

OK OK, China ist weit weg und wer hat schon ein Konto in China? Ich möchte aber noch einmal anmerken, dass auch bei uns und in den USA bereits Ideen aus der Regierung gekommen sind, nur noch Verschlüsselungen zu erlauben, welche auch „geknackt“ werden können… Oder erinnert euch an die Idee, jede Verschlüsselung ebenfalls noch einmal mit einem speziellen Schlüssel der Regierung mit verschlüsseln zu müssen? So das die Regierung in jedem Fall die Möglichkeit hat alles zu entschlüsseln! Natürlich alles zur Terrorabwehr… versteht sich von selbst!

So anstrengend unsere Aluhüte manchmal sind… Sie retten auch unsere Freiheit!

Danke Jost!

Kleinere Schlüssel als 2048bit sollte man mit Elliptic Curve Diffie-Hellman (ECDH) ja nicht mehr nutzen. Seit Java Version 1.8 ist dieses auch unterstützt. Wer also seinem Openfire xmpp/jabber Server diese Möglichkeit unterschieben möchte, sollte auf ein Oracle Java 1.8 setzen!

Wie also nun Java 8 dazu überreden? Auf einem Debian 8 (jessi) oder ähnlichem klappt es, wie folgt:

Möglichkeit Nummer 1. Zentral für alle Java Prozesse:

$ vim /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security

jdk.tls.ephemeralDHKeySize=2048

Möglichkeit Nummer 2. Nur für den Openfire, einfach beim Start mit übergeben:

$ vim /etc/default/openfire

# Additional options that are passed to the Daemon.
DAEMON_OPTS="-Djdk.tls.ephemeralDHKeySize=2048"

Um zu prüfen ob alles auch sauber umgesetzt ist hilft wie immer xmpp.net:

https://xmpp.net/result.php?id=7146

https://xmpp.net/result.php?id=7134

Oh ja, über Openfire AES 256 und JCE Unlimited Strength Jurisdiction Policy Files  müssen wir jetzt nicht mehr sprechen, oder? Ebenfalls nicht darüber, wie bei Openfire unsichere Cipher und Protokolle deaktivieren, oder?

Puhh… das was angenehm einfach oder? Bei Fragen, fragen 😀