Wie ich sehe sind die offenen SMB Ports raus, anbei weitere Findings:

• Darf HTTP Methoden HEAD, OPTIONS, TRACE nutzen.
• Server ETags werden gepetzt
• Referer Links werden gepetzt
• Application Server Jigsaw 2.2.5 aus dem Jahr 2005?!??
• Offenes Skript bzw. Fehl-Konfiguration AWstats: https://www.pilotundflugzeug.de/cgi-bin/awstats.pl
• eine Menge offener INDEX Verzeichnisse z.B.: https://www.pilotundflugzeug.de/servlet/ inkl. DS_Store Dateien vom Mac. wo interessante Metadaten zu entnehmen sind.
• Cookies nicht mit "httponly,secure" geschützt zumindest nicht auf https://office.airworkpress.com/login.php jeder MITM z.B. in einem WLAN kann Sessions übernehmen und ohne Passwort in Euren Mails lesen.

Ich kann zwar nicht so toll mit IT Fachbegriffen um mich werfen, aber mitteilen, das auf meinem iPad die grafischen Elemente nicht mehr funktionieren. Auf dem iPhone (mobile Version?) sieht es gut aus.

Nette Analyse. Sehr unprofesionell, diese hier im Forum öffentlich zu posten.

Ach Gottchen, das ist doch noch lange keine Analyse. Das war in 3 Minuten im Vorbeigehen aufgesammelt, nichts was ein böser Chinese, Russe oder Ukrainer nicht längst schon wissen um hier die gängigen Stereotypen zu bedienen.

Wenn Jan schon martialisch mit Totenköpfen freundliche Grüße an irgendwelche "nimmermüden Schürfer-Scripte" schickt, so verdient er es zu erfahren, was diese so wissen.

Ich sage Dir mal was eine Analyse wäre: Wenn der Bildupload inkl. serverseitiges Parsing der EXIF Informationen einmal analysiert würde, wie es sich mit manipulierten Dateien mit entsprechender Payload verhält. Was passiert eigentlich, wenn ich

Google mal "responsible disclosure"! Es ist schlicht absolut unterirdischer Stil, Sicherheitsprobleme öffentlich zu postenl, ohne dem Verantwortlichen vorher genug Zeit zu geben sie zu bereinigen.

Und das Argument "die Russen/Chinesen/Auserirdischen... finden die doch auch locker" ist in dem zusammenhang ziemlich absurd. Jeder, der auch nur halbwegs Ahnung von Computersicherheit hat, weiss, dass es natürlich keinen Schutz gegen wirklich professionelle Hacker gibt - aber die werden aicher nicht dieses Forum angreifen. Es geht um Gelegenheits-Script-Kiddies. Und die lockt man mit solchen disclusures durchaus an.

Wem es bisher nicht klar war, der weiß es jetzt: Du bist nichts als ein Profilneurotiker !

Was für ein Schwachsinn... und wenn Du mein verlinkes Negativbeispiel sehen würdest ist mir responsible disclosure sehr wohl bekannt.

Erik, du meinst, er ist ein "Möchtegern Groß"? Wenn ja, denken viele vermutlich schon länger... Im Austeilen ist TJ groß und eher nicht dezent. Aber wehe, man hält ihm was vor. Für mich gilt, wer austeilt muss auch einstecken können....

und wenn Du mein verlinkes Negativbeispiel sehen würdest ist mir responsible disclosure sehr wohl bekannt.

Ah ja - wenn Du dafür bezahlt wirst, dann hälst Du Dich also an die Regeln - nur unbezahlt posaunst Du Sicherheitsprobleme einfach so raus.

Sorry, aber das ist echt schlechtest denkbarer Style.

Ach Gottchen, das ist doch noch lange keine Analyse. Das war in 3 Minuten im Vorbeigehen aufgesammelt.

... oje, entsprechend schlecht ist der Beitrag auch. Also erstmal: Ohne GET Methode wird's schwierig für so einen Web-Server in der Praxis - gelle? Ach ja, sehe Sie hatten das in Ihrem Beitrag inzwischen korrigiert ... immerhin ...

Aber:

• Cookies nicht mit "httponly,secure" geschützt zumindest nicht auf https://office.airworkpress.com/login.php jeder MITM z.B. in einem WLAN kann Sessions übernehmen und ohne Passwort in Euren Mails lesen.

Geht's noch? Könnten Sie bitte aufhören mit Ihrem Halbwissen solche unwahren und höchst schädlichen Behauptungen aufzustellen? Um hinter dem horde php Mails lesen zu können müssten da nämlich auch Mails liegen. Vielleicht sind wir ja auch aus einem bestimmten Grund einfach nur neugierig wer so eine Login-Maske [schauen Sie sich mal die Form-Action an...] alles in die Finger nimmt?

CSP img-src:*

Ja klar oder meinen Sie ich will alle seit 2003 hier fremd-geposteten Bilder aus dem Forum kicken?

Jigsaw 2.2.5 als Backend in einigen Bereichen

So what? Ergibt sich daraus irgend ein bekannter Angriffsvektor der auf der Seite nutzbar wäre? Oder ist das einfach Berater-Gesabbel aus dem Hause jakobssystems.net ?

Referer und ETags

Das dürfen wir schon noch selber entscheiden - oder? Sie brauchen die Seite ja nicht zu nutzen wenn Ihnen diese Policy nicht gefällt.

GeoIP-Filtern [für China, Russland etc.]

Gute Idee! Die Seite wird ja auch kaum von Leuten genutzt die beruflich viel im Ausland unterwegs sind! Von der redaktionellen Arbeit ganz zu schweigen.

Ich bin ja wirklich froh für qualifizierte Hinweise, von mir aus auch öffentlich solange sie keine Exploits erlauben oder Daten enthalten. SMB-Port und Directory Listing im servlet-tree hätten z.B. wirklich nicht sein dürfen und sind gefixed. Danke dafür.

Aber einfach zu behaupten jeder MITM könnte unsere Mails mitlesen nur weil man irgendwo ein horde php ohne secure-cookie prefix gefunden hat ist schon üble Nachrede und zeigt die fachliche Güte der "Findings".

viele Grüße,
Jan Brill

Falsch Du liegst schon wieder völlig neben der Sache, es ist ein kostenloser Service.

Um hinter dem horde php Mails lesen zu können müssten da nämlich auch Mails liegen. Vielleicht sind wir ja auch aus einem bestimmten Grund einfach nur neugierig wer so eine Login-Maske [schauen Sie sich mal die Form-Action an...] alles in die Finger nimmt?

Interessant das Horde FORM Tag lädt auf (http:?) sich selbst? Da der Server diverse Mail-Ports offen hat, war das eine naheliegende Deduktion, daß ein instaliertes Horde am gleichen Host zum Lesen von Mails verwendet wird. Wenn es demnach nicht so ist, was hat dann das Horde auf dem Server zu suchen? Und das offensichtlich in einer älteren Version? Angriffsfläche minimieren, weg damit! Und btw. Horde besteht aus einer Vielzahl von Skripten und Funktionen, da ist es unerheblich ob aktiv genutzt oder nicht, irgendein Upload-Tool für eine PHP Reverse Shell ist da schnell gefunden.

Ja klar oder meinen Sie ich will alle seit 2003 hier fremd-geposteten Bilder aus dem Forum kicken?

Die Abwägung ist in der Tat zu treffen. Gefährde ich den unbeteiligten Betrachter, der über Google zufällig auf die Seite kommt mit irgendeinem fremd verlinkten Content, der Malware streut? Die Antwort ist leicht. Sobald das passiert, ist der Betreiber in der Haftung. Nur so zur Info.

Jigsaw 2.2.5 als Backend

Mitnichten Berater-Gesabbel. Ein Webserver aus dem Jahr 2005 ist ein Sicherheitsrisiko, da die ganzen Entwicklungen des vergangenen 13 (!) Jahre nicht enthalten sind. Oder verwendet irgendeiner der hier Anwesenden noch ein Windows XP oder einen IE6? Das Zeug stammt auch aus der Zeit herum.

GeoIP-Filtern [für China, Russland etc.]

Gute Idee! Die Seite wird ja auch kaum von Leuten genutzt die beruflich viel im Ausland unterwegs sind! Von der redaktionellen Arbeit ganz zu schweigen.

Risikoabwägung was normale Besucher/Nutzer der Website betrifft. Das Zugriffslog könnte da auf diese Frage Antwort geben. Was hingegen der redaktionellen Arbeit mit der Seite betrifft, gerade wenn Zugriffe auf die eigene Infrastruktur aus so Ländern wie China, Russland & Co erfolgen, dann sollte das ausschliesslich über ein VPN Tunnel erfolgen. Alles andere ist grob fahrlässig

SMB-Port und Directory Listing im servlet-tree hätten z.B. wirklich nicht sein dürfen und sind gefixed. Danke dafür.

Bitte

Aber einfach zu behaupten jeder MITM könnte unsere Mails mitlesen nur weil man irgendwo ein horde php ohne secure-cookie prefix gefunden hat ist schon üble Nachrede und zeigt die fachliche Güte der "Findings".

Falsch, ich brauche nur mit einem Wifi Pineaple in der Nähe Deines Notebooks zu sein, ein offenes WLAN unter der Dir bekannten MAC/SSID aufzuspannen und schon bucht sich Dein PC automatisch ein ohne daß Du was davon mitbekommst und ich kann nicht nur "mitlesen" sondern ungeschützte Cookies auch zur Sessionübername nutzen. Das ist mitnichten üble Nachrede.

Wie oben geschrieben, martialisch mit Totenkopf-Bildchen herum wedeln ist eine Sache. Die Realität kann mitunter anders aussehen.

Ich habe noch ein Problem auf aktuellem Chrome. Beim Absenden eines Posts verstößt der anschließende Redirect wohl gegen CSP und wird geblockt. Die Seite bleibt auf dem Post-Editor stehen. Das Posting ist jedoch vorhanden.

MessageEdit.class?showNew&parent=2018,12,15,12,0110688:1 Refused to send form data to 'https://www.pilotundflugzeug.de/' because it violates the following Content Security Policy directive: "form-action 'self'".

Ist da evtl. noch ein hartkodiertes "http" statt "https"? In der Fehlermeldung darüber steht übrigens "http", es scheint für die Anzeige im Forum automatisch in https geändert zu werden.

Ich kann den Ärger sehr gut nachvollziehen. Allein, ich befürchte, der Versuch einer sachlichen Auseinandersetzung führt in diesem Fall ins Leere.

TeeJay,

Sie versuchen mit möglichst viel IT-Sprech hier die Mitleser zu beeindrucken die nicht nachvollziehen können wie haltlos Ihre Argumente sind. Die ITler wissen das ja eh. Deshalb nochmal auf Deutsch für zwei Aspekte aus unserer Diskussion:

1) Sie behaupten jeder Man in the Middle (MTIM, Mithörer im Netzwerk) könnte unsere Mails lesen, weil die Eingagstür (Horde login.php) einen kriminellen Angriff nicht komplett verhindert. Was ich Ihnen geschrieben habe ist: In dem Haus in das diese Eingangstür führt gibt es keine Mails. Nur jemanden, der sehr interessiert ist wer durch diese nicht komplett verschlossene Tür hindurchkommt. Ist das echt so schwer zu begreifen?

Oder nochmal im IT-Sprech: "Horde ain't doing no webmail dude!"

2) Sie vergleichen die Auswahl eines Betriebssstems mit der Auswahl eines sehr eingeschränkt genutzten Werkzeugs (hier http-Bilbiothek) und leiten aus a) die Kriterien für b) ab. Den von mir geforderten Beleg eines Anfriffsvektors dadurch bleiben Sie schuldig und flüchten sich in Allgemeinplätze. Dass ich ein Betriebssystem anders auswähle als ein sehr gezielt genutztes Einzelwerkzeug dürfte auch IT-Laien einleuchtend sein. Wenn Sie Ihre Kunden mit der gleichen differenzierten Betrachtungsweise beraten bin ich froh da nicht dazuzugehören.

viele Grüße
Jan Brill

... auch in diesem Fall gelingt die Umkehrkurve nicht.

zu

1) Nocheinmal, bitte genau lesen! Auch Wenn Horde nicht zum Mail-Lesen genutzt wird, dann runter mt dem Zeugs! Denn auch bei Nicht-Benutzung ist diese lose Skriptsammlung geeignet, den Server zu kompromitieren sobald ich da eine Möglichkeit habe, eine Reverse Shell hochzuladen. Eine PHP-Zeile reicht aus. Und da es sich dem ersten Anschein nach auch um eine ältere Version handelt, ist da die Wahrscheinlichkeit eher hoch.

2) Okay dann wähle ich anstelle eines Betriebssstems ein etwas mehr vergleichbares Werkzeug: den IIS6. Und für die Java Software mag es nur eine eingebundene Bilbiothek sein. In Wirklichkeit ist das ein vollständiger Webserver, der seit 13 Jahren nicht mehr gepflegt und weiterentwickelt wurde.

Was Du als Betreiber mit den Findings macht, Deine Sache, ich bin nur der Messenger nicht die Message. Deine übrigen Ausfälle ignoriere ich da mal.

Hier ein schönes Video als weiterführende Information...

https://media.ccc.de/v/2018-139-die-fabelhafte-welt-der-information-security

Ich habe noch ein Problem auf aktuellem Chrome. Beim Absenden eines Posts verstößt der anschließende Redirect wohl gegen CSP und wird geblockt. Die Seite bleibt auf dem Post-Editor stehen. Das Posting ist jedoch vorhanden.

Hallo Achim, stimmt, das konnte ich reproduzieren. Chrome blockt in der CSP: form-action alle (!) redirects nach Form-Submission. Nicht nur die 308er. Der hässliche Workaround ist:

form-action 'self' www.pilotundflugzeug.de data: http: https:;

Jan

Herzlichen Dank dafür, dass die Seiten mit wirklich sparsamen Einsatz von Trackern auskommen!

Tracker sind mir wesentlich unsympathischer und inbesondere auch sicherheitstechnisch unheimlicher als "fehlende" CSP-Tags & Co., oder die Unterstützung von TLS 1.0 für die Leute, die noch mit Android 4.x-Browsern unterwegs sind.

Und danke für die Inkaufnahme der Mühsal, die der Betrieb der Seite mit sich bringt.

P.S.: Und danke für die sonstigen Fortschritte in 2018 - insbesondere die Vernichtung des Flash-basierten Bilderuploads und das Reenablen von Pmails!

Was Du als Betreiber mit den Findings macht, Deine Sache, ich bin nur der Messenger nicht die Message.

Sie sind wirklich schmerzfrei, das muss ich zugeben. Sie behaupten öffentlich Mängel die objektiv nicht bestehen und machen sich mit Allegmeinplätzen und Nebelkerzen wichtig.

Beantworten Sie mir doch einfach meine simple Frage: Wo verläuft der Angriffsvektor in der genutzten Funktionalität von Jigsaw? Der steht ja nicht irgendwo rum, sondern kann nur das tun was der (natürlich halbwegs aktuelle) apache zulässt.

Einfach zu blöken: "Die Bibliothek ist 13 Jahre alt" reicht halt nicht. Das ist Wichtigtuerei. Also ... Butter bei die Fische, bitte!

viele Grüße,
Jan Brill

Sie stellen eine konkrete Frage und erwarten eine sachliche Antwort von TJ? Alle Achtung! :-)

Muss ich Dir wirklich erläutern, was "Stand der Technik" bedeutet? Aber nun gut, da Du nach einer klaren "sachlichen" Antwort gebeten hast. Nichts einfacher wie das: Hier der Link auf das Changelog der "aktuellen" (aus 2007, was für eine Farce) 2.2.6er Version was so alles in Deiner 2.2.5er an Bugs schlummert, einige davon klingen gar nicht mal so übel wenn ich böses im Schilde führen würde:

• Fixed cookie parsing bug, if the cookie value contains a '='
• Fixed SAX parsing of stores and remote resource description (allow multiple 'characters' call for one value)
• Removed an unneeded synchronization point in HTTPFrame.getURL()
• Added an extra SP when exporting auth headers with different components
• Fixed source code to remove 'enum' as it is now a keywork starting with JDK 1.5
• Fixed client connection deletion in connection reuse, it was leading to a leak in the client hashtable (and to lots of connections in CLOSE_WAIT).
• Fixed bug in DateParser (wrong timezone offset) thanks to Menno Jonkers
• Optimized a bit Digest Auth (the RFC2069 one) and implemented Digest Auth with qop="auth" per RFC2617 (available with SecurityLevel set to 2), See DigestQopAuthPrincipal
• Fixed a few WebDAV properties that were using wrong formats
• HeaderFilter now sets the relevant headers even when the reply is sent via the exception mechanism.
• More SSL and servlet related patches from Thomas Kopp.
• ActiveStream patch, under some condition, the same data could be re-read a data chunk (thanks to Doug Borland)
• The servlet parameter decoding now uses the right charset.
• Fixed error when file timestamp was not modified but the file was actually modified.
• Fixed deadlock during store change notification when the sweeper is running (very rare)
• Fixed server client count when load is raising from LIGHT to DEAD
• Fixed Segment information unpickle, as the segment start and size were not properly parsed, leading to an infinite loop
• More SSL patches from Thomas Kopp, see changelog for more details.
• Fixed connection count when MimeParser did not started and connection was new.
• Client stack now reuses the connection timeout parameter.

„einige davon klingen gar nicht mal so übel wenn ich böses im Schilde führen würde“

Mit Verlaub, aber Du führst Böses im Schilde.