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

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

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.

Ach noch eine Sache, aber vermutlich auch nur eine Nebelkerze oder etwas, was bestritten wird:

https://privacyscore.org/site/118436/

sagt, daß der Google Tracker offensichtlich nicht mit AnonymizeIP eingebunden ist. Die DSGVO lässt grüßen! Schlimm, daß dieses Zeugs überhaupt auf einer Website ist, aber das lässt sich wohl nicht vermeiden.

Herr Jacobs, ich verstehe nicht mehr was Sie mit diesen Beträgen eigentlich bezwecken.

Vielleicht kann ich zumindest meinen Standpunkt nochmal zusammenfassen:

Sie beantworten die konkrete Frage nach Angriffsvektoren oder Sicherheitslücken mit dem Einkopieren einer Buglist. Die meisten Sicherheitslücken gehen zwar auf Bugs zurück aber lange nicht alle Bugs führen auch zu Sicherheitslücken. Einen Beleg für die von Ihnen behaupteten Mängel liefern sie so nicht.

In die Diskussion um Sicherheitslücken bringen Sie dann den privacy-score Report ein. Auch ein interessanter Aspekt – und es gibt sicher Schnittmengen – aber eben nicht das Thema. Es steht Ihnen frei die Seite nicht zu nutzen, wenn Sie mit den erklärten Privacy-Richtlinien des Betreibers nicht leben können. Also wie Sie schon richtig selber sagen: Klassische Nebelkerze.

Genauso bei Ihrem php-finding. Wenn sich Ihre Behauptung zur Mail-Unsicherheit nicht mehr halten lässt, weil sie dahingelabert war ohne auf die konkrete Anwendung einzugehen, wechseln Sie auf Allgemeinplätze und erzählen was von Reverse-Shell ohne zu erläutern wie die denn konkret auf den Server kommen soll. Ihr Argument: Eine Zeile Code kann hier einen Mega-Schaden anrichten. Stimmt. Aber das können auch die ca. 2.000 Bytes im Private Key.

Es ist doch eigentlich nicht so schwer. Die von uns eingesetzte und teils auch entwickelte Software beinhaltet zweifellos eine große Zahl von Fehlern.

Sie beinhaltet auch eine – zweifellos deutlich geringere – Zahl von Sicherheitslücken. Die Anzahl der Sicherheitslücken ist aber > 0, das ist klar.

Sie haben sich entschieden öffentlich ein paar "Findings" (welcher Level eigentlich?) hinzurotzen. Einige davon waren richtig, über andere können wir Monate diskutieren und einige sind einfach falsch oder zeigen zumindest eine recht oberflächliche Herangehensweise, da Sie nicht berücksichtigen wie und in welchem Umfang eine Software eingesetzt wird.

Hätten Sie mir das gemailt, hätte ich "danke für den Hinweis" geantwortet, mir die Sachen rausgesucht mit denen wir hier einverstanden sind und den Rest ignoriert.

Sie wollten das alles aber unbedingt öffentlich machen. Also wehre ich mich auch öffentlich. Optimal ist das für uns beide nicht aber die Entscheidung das im Forum zu machen war Ihre.

Stellen Sie sich doch einfach mal die Frage: Einer der vielen Unternehmer hier im Forum sucht vielleicht gerade einen IT-Dienstleister. Ist er nach der Lektüre dieses Threads, der durchaus Rückschlüsse auf Ihre Arbeits- und Argumentationsweise erlaubt, mehr oder weniger geneigt Tomas Jacobs von jakobssystems ltd in Siegen zu engagieren?

viele Grüße,
Jan Brill

Lieber Jan!

LAss Dich nicht kirre machen. Das P&F-Forum ist eine wunderbare Informationsquelle. Diese Quelle wird gespeist von Schwarmintelligenz und sehr nützlich und etabliert, sogar über DACH hinaus. Leider gibt es in so einer sehr wünschenswerten Einrichtung ein paar schwache Gemüter, welche ihr (Halb-)Wissen jedem und permanent aufdrängen. Der Gestank eines guten Käses. Wäre ich mit behördlicher Macht gesegnet, würde ich mindestens einem halben Dutzend Teilnehmer hier die Lizenz - vor allem die Lehrberechtigung - schreddern. Das wäre mal eine nützliche ZÜP! Wie können wir ahnungslose Schüler z.B. vor Fluglehrern wie hier schreibende Psychopathen schützen? Lass bitte das Forum so wie es ist. Die schönste Parkbank kann nichts dafür, daß eine Krähe drauf kackt. Deshalb die Bank entfernen? Ich habe mir einen mentalen Filter nach dem Öffnen des Forums zugelegt, schmeiß den Beifang sofort über Bord sehe ich den Autor, scrolle weiter und lese Lehrreiches und Amüsantes.

Si tacuisses...

Neulich bin ich mal mit jemandem geflogen, der mich immer kostenlos sein Flugzeug benutzen lässt. Er sagte mir, dass er vor kurzem ein ganz tolles Proficiency-Programm absolviert habe, und außerdem sein Flugzeug drei Tage von der ACAM-Truppe auf links gedreht wurde - da war ich doch sehr gespannt.

Das Bemühen in allen Ehren, aber das Ergebnis war doch mehr als ernüchternd:

- Schon beim Anlassen ging es los: Wir standen auf einem ARFF-Class-1-Airport (eigentlich unverantwortlich, da überhaupt zu landen - die können dort kaum einen brennenden Weihnachtsbaum löschen!) und der Feuerlöscher an Bord entsprach nicht der DIN-EN-3, sondern nur der wesentlich schwächeren NFPA-10, was bei einem Vergaserbrand in diesem Flugzeug mit IO-360 (der ist da bekanntlich berüchtigt dafür) schnell verheerende Folgen hätte haben können.

- Beim Taxiiing gab es deutliche Abweichungen von der Centerline - kein Wunder: Weder war ein Synthetic Vision System, noch eine simple Nosegear-Cam vorhanden. Beides absolut Stand der Technik heute!
RTCA DO-315 ist da vollkommen eindeutig.

- Die Identifikation der Takeoff-Runway erfolgte ausschließlich über die Runway Markings, das ADAHRS des Flugzeugs und den Magnetkompaß. Keinerlei Crosscheck über GSM-Triangulation oder den Abgleich des Runway Edge Light Spacings mit ICAO Annex 14, Abschnitt 5 oder dem ICAO-Doc 9157. Fluxgate-Spoofing über die FLARM-Schnittstelle ist für die bösen Buben ein Kinderspiel!

Und so ging es den ganzen Flug weiter. Ich habe mir dann überlegt, wie man diese gravierenden Defizite am Besten adressiert. Ein persönliches Debriefing wäre eine Möglichkeit gewesen, aber nachdem der Mann ganz viele Leute sein Flugzeug benutzen lässt und - gerade im Bezug auf die erwähnten technischen Defizite - absolut Gefahr im Verzug war, habe ich mich für einen Aushang der Findings am Schwarzen Brett seines Heimatflughafens entschieden.

Toll finde ich, dass er mich sein Flugzeug nach wie vor nutzen lässt - ich mit meinem überlegenen Können brauche diese viele Technik auch nicht, und ganz nett ist der Flieger ja doch...

;-) Ganz großes Kino ... um das zu lesen hat sich der ganze Aufwand heute doch schon gelohnt!

Die besten Hofnarren spielen umsonst auf - weil sie nicht merken, dass sie welche sind.

Tobias, danke für den Beitrag. Einfach nur gut!

Jan, chrome geht bei mir auch wieder ...

Ach weisst Du Jan,

die offenen SMB-Shares sind entfernt und einige andere Findings sind auch weg. Gut so!

Die Diskussion zum Horde ist... Ein System offen am Web zu betreiben, das offensichtlich nicht genutzt wird ist ... wie soll ich es nennen, ohne daß es gleich beleidigend klingt? Jeder MITM kann sich durch Phishing der Anmeldeseite oder Session-Übernahme Dein Kennwort annehmen. Ohne VPN oder 2FA ist die Nutzung solcher einfachen Systeme fahrlässig, gerade wenn jemand aus besagten Ländern wie China & Co arbeiten will. Fahrlässig ist es auch 13 Jahre alte Applikations-Server Software offen am Netz ohne zusätzliche Schutzmaßnahmen zu betreiben. Und ein Apache-Reverse Proxy reicht die Dinge nur weiter. Das wird Dir jeder andere Security-Experte genauso sagen.

Und da mein Hinweis auf Dein Datenschutzproblem als Sicherheitsproblem aufgefasst wurde, lass' es Dir einmal kurz erklärt sein: Eine datenschutzkonforme Nutzung von Google Analytics ist nur mit der AnonymizeIP Funktion möglich. Da PrivacyScore anzeigt, daß diese nicht gegeben ist, wäre es schön wenn Du das auch noch richtig implementieren würdest.

Dein restliches Gejammere oder dieses kindhafte "Mama, er hat mich gehauen - ich muss mich jetzt auch wehren" lassen wir mal beiseite. Wer mit martialischen Sprüchen über Sicherheit inkl. Illustrationen von Totenkopfbildern ausholt, der sollte auch den Gegendruck auszuhalten. Einstecken und Austeilen - wie beim Fußball.

In der Tat lassen sich nach der Lektüre dieses Threads gewisse Rückschlüsse auf Arbeits- und Argumentationsweise und grundlegende Defizite hinsichtlich Informationssicherheit schliessen.

In diesem Sinne.

Oder um es in den Worten Bruce Schneiders zu sagen:
"Public scrutiny is the only reliable way to improve security."

P.S: ich leiste mir den Luxus, Projekte und Kunden selbst aussuchen zu dürfen.

Dafür, dass Du hier sein Gast bist ist Deine Unverschämtheit und Überheblichkeit kaum zu fassen.

Zum Fremdschämen!

Lieber Jan,

danke, dass Du dieses Forum hier - und dann noch kostenlos - betreibst. Lass Dich von den Nörglern nicht aus dem Konzept bringen - egal, ob es um Email-Funktionen oder angebliche Sicherheitsprobleme geht.

Was das Sciherheitsthema anbelangt: Absolute Sicherheit solcher Systeme gibt es nicht. Das weiss eigentlich jeder, der sich mit so nem Thema wirklich auskennt. Daher können Schutzmassnahmen immer nur im Verhältnis zum möglichen Schaden sinnvoll beurteilt werden.

Dies hier ist ja kein System, in dem Startcodes für Nuklearwaffen verwaltet werden. Es ist ein Diskussionsforum für Piloten und Luftfahrtinteressierte. Da ist das Gefährdungspotential relativ gering.
Das Schlimmste, was passieren kann, ist, dass sich jemand in einem fremden Account reinhackt und z.B. mit der Identität eines UL-Fluglehrers abstruse Theorien zu Umkehrkurven verbreitet, was natürlich der Reputation dieses Nutzers und vielleicht sogar der ganzen Zunft schaden kann - aber selbst das läßt sich nachträglich relativ schnell beheben, wenn es passieren sollte...

Bitte einfach weiter so!

ich leiste mir den Luxus, Projekte und Kunden selbst aussuchen zu dürfen.

Angesichts der massig vorhandenen Freizeit für die aufregendsten Flugabenteuer ist man nicht versucht, etwas Anderes anzunehmen. Und dann noch diese vornehme Bescheidenheit!

Max, kein Neid!

Wenn man ein Monopol wie TJ hat (siehe Homepage oder Foto), kann man sich das leisten!

"Dein restliches Gejammere oder dieses kindhafte "Mama, er hat mich gehauen - ich muss mich jetzt auch wehren" lassen wir mal beiseite."

Dieser ungezogene Stil ist einfach nur noch zum Kotzen! Ich bewundere den Langmut von Jan Brill. Ich hätte Dich aus diesem Forum längst rausgeschmissen. Aber bei den zahlreichen Sicherheitslücken und Deinen Fähigkeiten würdest Du dich vermutlich einfach wieder auf die Seite hacken.

Willi, da hast du was gesagt. Bei mir wäre er auch schon weg, was laut meinem Kenntnisstand in anderen Foren bereits der Fall war.

Wollen wir eine petition starten :-)?

Hallo zusammen,

sehr schade, dass die Diskussion so schnell von der fachlichen Ebene weggedriftet ist. Web-Security ist und bleibt ein ewiges Katz-und-Maus-Spiel. Gerade das machts eigentlich so spannend und interessant.

Auf die ganze TJ-Thematik gehe ich mal nicht ein, der hat schon genug Feuer abbekommen. Etwas schade fand ich folgende Argumentationslinien:

• Achims Argumentation (Post vom 14.12.2018 um 18:58), dass zu viel Aufwand in die Security nicht lohnt, da ein Angreifer immer unentdeckte Sicherheitslücken finden wird. Ich denke, dieser Argumentation liegt die falsche Annahme zu Grunde, dass es nur die zwei Zustände "sicher" und "nicht sicher" gibt. Dies ist aber falsch. Investition in Security ist immer ein Aufstellen von Hürden, die es einem Angreifer schwerer machen, in ein System einzudringen. Es ist quasi ein Kostentreiber für die Gegenseite. Wenn alle bekannten Schwachstellen zu sind, muss ein Anfreifer auf unbekannte Schwachstellen zurückgreifen. Diese zu finden, braucht mehr Kenntnisse, mehr Zeit und erzeugt damit mehr Kosten, so dass er es im Zweifelsfall nicht mehr tun wird, weil das Ziel nicht mehr lohnenswert genug ist. Deswegen muss die US Army mehr Geld in Security investieren als der Trachtenverein Hinterburladingen.
• Jans Argumentation des "Love it or leave it" (Post vom 15.12.2018 um 12:01), im konkreten Fall gings um die Referrer-Einstellung. "Love it or leave it" ist meines Erachtens ein gefährliches Totschlagargument, da es jede weitere Diskussion abwürgt. Jan, in der Fliegerei kritisierstdu das zu Recht, wenn sich Personen sachlichen Argumenten verschließen und auf Stur schalten.
• Die "Abteilung Angriff", die inhaltlich wenig-garnichts zur Sache beigetragen hat, allerdings in jedem Post von TJ das Haar in der Suppe sucht und dieses entsprechend ausweidet. Besonders hervorgetan haben sich hier Willi, Wolff und Erik. Willi z.B. bereits im dritten Post des Threads an einer etwas flapsigen Formulierung, obwohl der zitierte Post inhaltlich an sich i.O. war.
  
  

Da ich selbst Website-Admin bin und mich zumindest grundlegend mit der Security-Thematik auseinandergesetzt habe, hier noch ein paar Hinweise an Jan Brill von meiner Seite. Eins vorab: Ich mache das hier nicht, um mich als besonders toll oder allwissend herauszustellen. Es geht mir auch nicht darum, jemandem eins reinzuwürgen. Jan stellt einen tollen Service kostenfrei bereit und im Gegenzug will ich kostenfrei meine Zeit aufwenden, um ihm dabei zu helfen, den Service besser zu machen. Das Schreiben dieses Posts kostet mich auch immerhin 30-45 Minuten meines Sonntags nachmittags.

Datenschutz:

• Referrer-Policy: Ist natürlich deine Entscheidung. Falls du PuF-Intern mit Referern arbeitest, würde sich als Policy "strict-origin-when-cross-origin" "same-origin" anbieten, dann bleibt intern alles beim alten, nur nach außen wird der Referrer unterdrückt.
• Google-Analytics Anonimize-IP: Ob das jetzt aktiv ist oder nicht, kann ich nicht beurteilen. Mir ist allerdings aufgefallen, dass es in der Datenschutzerklärung explizit drin steht. Meine Empfehlung ist drauf zu achten dass dann entweder aktiv ist oder aus der Erklärung rausgenommen wird.

Webserver:

Als Jigsaw-Betreiber stellst du tatsächlich eine Minderheit im Internet dar. Es hat wahrscheinlich mit dem komplexen System zu tun, das da dahinter hängt. Wenn ich das richtig gesehen habe, läuft der dynamische Teil der Website über Java. Hast du mal geprüft, ob es möglich ist, den Jigsaw durch einen Apache Tomcat oder einen Jetty zu ersetzen? Auch diese bieten die Möglichkeit Java-Applikationen als Webservices zu betreiben.

Zertifikat:

Hast du mal überlegt, von GoDaddy auf Lets Encrypt zu wechseln? Abgesehen vom Kostenvorteil erneuert sich das LE-Zertifikat auch von selbst, d.h. das 2-jährige einspielen des Zertifikats entfällt.

Nerd-Karma:

Wenn du dir noch ein bisschen Nerd-Karma verdienen willst, mach IPv6 an :-)

Kleinere UI-Bugs:

• Das Vorschaubild des aktuellen Hefts oben rechts wird nicht angezeigt (hatte ich ja schon per Mail geschrieben). Firefox/Windows10
• Der Button "Bewertungen anzeigen" ist ohne Funktion auf dem iPhone (Safari/iOS 12). Auf Firefox/Windows10 klappt alles wies sein soll.
  (Geht wieder)

Das sind so die Sachen, die mir noch aufgefallen sind. Wie gesagt, alles kann, nix muss.

Grüße

Jo

Nein. Einfach nicht fuettern. Aber auch nicht mobben. Cool bleiben. Wir sind schliesslich Piloten :-)