Kategorie: IT-Security (Seite 11 von 15)

Na wie geil ist das denn Bitte? Das SHA1 nicht der Brüller ist wissen wir ja inzwischen alle. Das man nicht (wie bei MD5) so lange warten sollte bis es nicht nur ein theoretisches Problem, sondern ein echtes gibt… Ja, das können sich viele denken. Leider bekommt man viel „Entscheider“ nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Ggf. müssen ja Softwaremodule getauscht werden, Hardware könnte ersetzt werden müssen usw. usw.. Windows XP wird so zum Beispiel abgehängt!

Denn noch überrascht mich Google in der letzten Zeit immer mal wieder hinsichtlich irgendwelcher Sicherheitsgeschichten. So nun ebenfalls wieder mit der Ankündigung, dass sie SHA1 aus ihrem Browser haben wollen. Nutzt man also Zertifikate mit SHA1 Checksumme, gibt es bald eine Meldung im Browser. Diese Meldung wird dem Anwender vermitteln: „Diese Seite ist nicht ganz sicher!“. Direkt gefolgt von einer deutlichen roten Meldung bis hin zum Punkt dass solche Zertifikate nicht mehr unterstützt werden sollen. Dieses erst so ab ca. 2017… Wenn man aber nun über die durchschnittliche Gültigkeitsdauer von „Kaufzertifikaten“ (2 Jahre) ausgeht… Tja, dann kann man so gesehen zum letzten mal mit ~gutem Gewissen~ ein SHA1 Zertifikat am 31.12.2014 kaufen. OK, man kann natürlich zu jeder Zeit ein neues Zertifikat mit SHA256 Checksumme erstellen, dieses kostet dann aber auch wieder Geld. Man kann sich also jetzt überlegen ob man zwei mal Geld bezahlen möchte oder nicht!

http://googleonlinesecurity.blogspot.de/ 

Was mir an Google so gefällt, ist dass sie im Moment immer mal wieder „sanften“ Druck auf die Entscheider ausüben um doch etwas mehr Sicherheit ins Internet zu bringen. SHA1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern, genau wie RC4, MD5 oder ähnliches. Kein Anwender wird dieses von sich aus prüfen und kein Anwender wird dieses von sich aus in Frage stellen. Beginnt die Anwendungssoftware zu moppern… Dann gibt es schnell eine gewissen „Nachfrage“ und somit Bewegung bei den Entscheidern oder den „weiter ==> weiter ==> fertigstellen Admins“.

Oh ja, Microsoft sowie Mozilla hegen sehr ähnliche Pläne! Ich habe das Thema ja schon einmal vor knapp einem Jahr aufgegriffen ( 27. September 2013). Sicheres SSL / TLS Zertifikat 
Meine Empfehlung ist also: „Testen ob ihr/eure Systeme mit SHA256 Zertifikaten umgehen können und vor den nächsten Kauf entscheiden, ob es wirklich noch mal ein SHA1 Zertifikat werden soll oder nicht..“!

Nur, wer hört schon auf mich? 😛

---

Na schau mal einer an…. Inzwischen „zucken“ sogar die großen CAs:

Wichtiger Servicehinweis
Sehr geehrte/r Sebastian van de Meer,

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1 einzustellen. Als erster Schritt ist geplant, die Vertrauenszeichen im Browser Chrome™ abzuschwächen und Warnmeldungen anzuzeigen, wenn eine Website mit einem solchen Zertifikat aufgerufen wird. Das wird voraussichtlich ab der Version 39 von Chrome geschehen, die für November 2014 geplant ist. Weitere Informationen sind in diesem Google-Blog erhältlich (auf Englisch). Symantec empfiehlt, dass Sie proaktiv die folgenden Maßnahmen ergreifen, um zu verhindern, dass Besucher diese abgeschwächten Vertrauensmarken oder Warnmeldungen sehen, wenn sie Ihre Website in Chrome 39 aufrufen:

1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015 ablaufen, kostenlos durch Zertifikate mit SHA-2. Weitere Informationen dazu finden Sie in Artikel SO7146 in unserer Knowledge Base (auf Englisch).

Hinweis: Root-Zertifikate mit SHA-1 sind nicht von dieser Änderung betroffen.

Weitere Informationen finden Sie unter:

• Symantec-Informationsseite zu SHA-1
• Symantec Community Forum: Website-Sicherheitslösungen (auf Englisch)
Falls Sie noch weitere Fragen haben, wenden Sie sich bitte unter der Adresse ssltechsupport_de@symantec.com an Ihr Support-Team oder setzen Sie sich mit Ihrem Account Manager in Verbindung.
Mit freundlichen Grüßen

Ihr Support-Team von
Symantec Website Security Solutions

##############################################################################################################################

Important Service Announcement
Dear Sebastian,

We would like to inform you of Google’s intent to phase out support for certificates using a SHA-1 hashing algorithm via degraded visual indicators and warnings in the Chrome™ browser. These changes are expected to take effect in the production version of Chrome version 39 in November 2014. You can find more information regarding the proposed plan on Google’s blog.

As a proactive measure, in order to help ensure that Chrome 39 users visiting your websites do not encounter any UI degraded indicators, Symantec recommends the following:
1. Identify certificates that have a SHA-1 algorithm using the Thawte Certificate Center or SSL Toolbox. For more information, please refer to Knowledge Center article SO26488.
2. Replace any SHA-1 certificates that expire beyond December 31, 2015 with SHA-2 certificates at no additional cost. For more information, please refer to Knowledge Center article SO13487.

Please note that SHA-1 root certificates will not be affected by the plan.

Here are some additional resources for your reference:

• Guidelines for Replacing SHA-1 certificates with SHA-2 on Thawte Trust Center
If you have additional questions, please contact your support team at
support@thawte.com.
Best regards,

Thawte Team

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

OK ok, ein altes Thema, denn noch habe ich es gerade an der Hand und somit kommt wieder ein kleiner Beitrag dazu hier 🙂

Man kann seine Server nicht zu 100% absichern. Um im Fall der Fälle einen kleinen Anhaltspunkt zu haben, lasse ich mir vom jeweiligen Server gerne eine E-Mail schicken sobald jemand eine root-shell öffnet. Selbstverständlich ist es Schlangenöl, wenn ich es als Security Feature bezeichnen würde! Warum ich es denn noch gerne einsetzte möchte ich daher kurz erklären.

Erlangt ein Angreifer (aus welchen Gründen auch immer) erweiterte Rechte auf einem System, möchte ich ungern erst später von Kunden davon hören…. Weil Mist auf der Webseite steht oder irgendwelche Abuse-Mails bei mir aufschlagen…. Hat sich ein Angreifer erweiterte Rechte auf dem Server erarbeitet, kann er natürlich seine Aktivitäten und Anwesenheit „verschleiern“.

Verschickt das System bei jeder Eröffnung einer root shell eine E-Mail an mich, habe ich zumindest einen Anhaltspunkt. Denn wenn sich auf irgendeinem Server jemand als root anmeldet ohne das ich eine solche Anmeldung erwarten würde und dann vielleicht noch von einer IP-Adresse, welche mir komisch vorkommt, ja dann habe ich meinen Anhaltspunkt dieses zu hinterfragen!

Natürlich sollte die verschickte E-Mail nicht an den gleichen Server geschickt werden, sonst frisst der Angreifer die E-Mail auf, noch bevor ich sie lesen kann. Da die E-Mail direkt mit dem Login verschickt wird, ist sie meist schon unterwegs, noch bevor der Angreifer sie aufhalten kann. Es ist und bleibt aber Schlangenöl!!!!

Die eigentliche Befehlszeile kursiert in den gängigen Suchmaschinen. Folgendes ist also copy & paste….

Das Programm mailx sorgt dabei für den Mailversand auf der Shell. Die folgende Befehlszeile tut nichts weiter als den letzten „SSH“-Login abzugreifen, den ~Absender~ des Logins heraus zu fummeln und es mir per E-Mail zu schicken. Damit es bei jedem Start der Bash des Users Root erfolgt, landet die Zeile im Home des Roots in der Datei: /root/.bashrc

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@kernel-error.com

Ich darf an der Stelle noch erwähnen, das ich meinem SSH-Server verboten habe DNS Abfragen zu tätigen. So landet in meinem Fall direkt die IP Adresse in der E-Mail und kein Hostname.

/etc/ssh/sshd_config

UseDNS no

Ein Login sorgt nun also für eine E-Mail mit folgendem Inhalt:

ALERT - Root Shell Access (dlg-srv88) on: So 3. Aug 19:28:18 CEST 2014 root pts/0 2014-08-03 19:28 (1.2.3.4)

Dieses kann nun auf gleichem Wege auf andere Benutzer ausgeweitet werden. Man könnte auch zusätzlich noch die letzten und wichtigen Logdateien anhängen. Ich denke aber es sollte nur ein Hinweis bleiben und nicht versucht werden zu einer Security Lösung ausgebaut werden, denn es greift sicher nicht in jedem Fall und es lässt sich ebenfalls aushebeln.

 

Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.

Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!

Die Installation ist recht einfach.

Zuerst einmal die neuen Policy Files herunterladen (für Java 7):

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html  

Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die….  na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:

/usr/lib/jvm/java-7-oracle/jre/lib/security
/usr/lib/jvm/jdk1.7.0_51/jre/lib/security

Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.

Clientreport:

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

Serverreport:

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

Noch Fragen? Na dann fragen 🙂

Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.

Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.

1. OpenFire beenden.

2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.

In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.

$ cd /etc/openfire/security
$ wget http://www.startssl.com/certs/sub.class2.server.ca.crt
$ cat sub.class2.server.ca.crt domain.tld.cert > domain.tld.cert.tmp

3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.

$ openssl pkcs12 -export -in domain.tld.cert.tmp -inkey domain.tld.key -out domain.tld.pkcs12 -name domain.tld

4. Als letzten Schritt kann ich nun das Zertifikat in den Keystore meines Openfires aufnehmen:

$ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /etc/openfire/security/keystore -srckeystore domain.tld.pkcs12 -srcstoretype PKCS12 -srcstorepass changeit -alias domain.tld

5. Openfire wieder starten.

Nun lässt sich bereits im Webinterface das neue Zertifikat sehen und ist nutzbar.

Noch Fragen?

WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen 🙂

---

CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:

Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten

Sehr geehrte Damen und Herren,

CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.

Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.

Format: ASN | IP-Adresse | FTP-Login

Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.

Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.

Liste der Zugangsdaten für Server in Ihrem Netzbereich:

 12345 | 123.123.123.123  | benutzername:IG******@ftp21.domain.tld

Mit freundlichen Grüßen
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn

————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.

Mein Jabber Server hat gerade neue Zertifikate bekommen. Die alten waren ausgelaufen…. Ich spare mit die Fingerprints, prüft bitte per TLSA 😀

 

So long…