BitCity Reloaded (Recheck)

[Rebound]

Tracker: BitCity-Reloaded
Source: NV-Source

"Winter is coming" fanden wir in diesem Fall irgendwie zutreffend, weshalb wir dieses Review damit einleiten wollen.

Im Rahmen unserer TOG-Reviews haben wir BitCity-Reloaded etwas eingehender untersucht. Dieser Tracker hat auf TOG am aggressivsten und gleichzeitig auch am primitivsten im TOG Forum für neue User geworben.


Serversicherheit

OS: Linux, Debian 8
Webserver: Apache
SSH: OpenSSH 6.7p1 Debian 5+deb8u7
PHP: 5.6.40-0+deb8u1
MySQL: 5.5.62
OpenSSL: 1.0.1t

SSH liegt nicht auf dem Standardport, was gut ist. Nicht so gut ist die PHPInfo, die direkt im Webroot liegt (fürs Archiv haben wir die PHPInfo unten angehängt). Ist natürlich nett, wenn man direkt alle Versionsnummern so präsentiert bekommt. Die PHPInfo im Webroot liegen zu lassen stellt einen klassischen Anfängerfehler dar.
Für die Firewall gilt das Gleiche wie bei den bisherigen Reviews auch: Falls eine existiert, ist sie nicht effektiv genug konfiguriert.


Trackersicherheit

Die Source sieht zwar besser aus als bei unserem letzten Review, das ist aber auch schon alles. Von Sicherheit kann man genau wie beim Server nicht sprechen. Wir konnten uns deshalb erneut Zugang verschaffen.

Proof

Auszug aus der Benutzertabelle hatten wir letztes Mal schon. Deshalb gibt es dieses mal ein paar Screenshots von einem Staffaccount.

Interne Statistiken









PM-Spion



Gebannte User




Extraservice von uns für euch

Als kleinen Bonus haben wir eine Seite geschaltet, mit der ihr euch eure Benutzerinfos von BC anzeigen lassen können. Was auch ganz interessant ist, dort werden euch auch die Staff-Kommentare angezeigt, die vom Staff oder vom System über euch verfasst wurden und normalerweise nur für den Staff sichtbar sind. Wir dachten, den einen oder anderen könnte das sicherlich interessieren.
Alles was ihr dafür tun müsst, ist eure Benutzer-ID von BC und den privaten Hash den ihr in unserer E-Mail erhalten habt dort eingeben.
Die Seite findet ihr hier: https://www.sb-innovation.de/pverifier.php

Wer keine E-Mail erhalten hat, kann sich gerne auch bei mir per PN melden. Dann erzeuge ich einen entsprechenden Hash für seinen BC-Account.

Als zweiten Service haben wir noch unser "Hash-Verifikationsverfahren" ins Leben gerufen. Ob sich das durchsetzen wird und ob andere Tracker daran interessiert sind wird sich zeigen. Weiterführende Informationen für User und Trackerbetreiber finden sich hier: https://www.sb-innovation.de/showthr...tionsverfahren


Fazit

Dieses Fazit wird lang, was an der endlos langen Liste von Fehlern liegt, die hier von BC Reloaded begangen wurden. Wir werden nicht mal alle auflisten. Dafür haben wir gar keine Zeit. Wie schon beim letzten Mal konnten wir die vollständige Datenbank kopieren und sichern. Es hat einige Tage gedauert alles auszuwerten, aber wir haben sehr Erschreckendes festgestellt. Hier liegt nicht einfach nur technisches Unwissen vor, sondern auch wirklich grobe (ganz ganz grobe!) Fahrlässigkeit auf mehreren Ebenen.

Der erste Punkt betrifft die Passwörter. Wir haben die Passworthashes mit denen von 2016 verglichen und mussten leider feststellen, dass fast niemand sein Passwort geändert hat! WTF? Wir hätten uns drei Jahre lang in fast jeden Account auf dem Tracker einloggen können. Offenbar hat BC seine User nie über den Hack von damals informiert und falls doch, den Usern nicht die angemessenen Maßnahmen empfohlen.

Der zweite Punkt betrifft wieder Passwörter, aber dieses mal Andere. BC Reloaded besitzt ein Bewerbungsformular, was in letzter Zeit auch von vielen TOG-Usern in Anspruch genommen wurde. Dort muss man seinen gewünschten Usernamen, sein Passwort, einen Link zu einem Bild von einem Referenztracker und einen Bewerbungstext eingeben. Alle angenommenen Bewerbungen sind im System gespeichert und befinden sich in unseren Händen. Wir sind fast vom Stuhl gefallen, als wir festgestellt haben, dass dort alle Passwörter im KLARTEXT gespeichert sind! WTF²? Wir sind nun im Besitz von über tausend Passwörtern von Leuten, die über das Bewerbungsformular auf den Tracker gelangt sind.

Als nächstes haben wir uns die Datenbank aus technischer Sicht angesehen. Wer davon keine Ahnung hat oder wen es nicht interessiert, kann diesen Abschnitt gerne überspringen. Auch hier hat jemand überhaupt keine Ahnung wie man eine Datenbank ordentlich konfiguriert.

1. Es werden für einzelne Tabellen teilweise völlig ineffiziente (falsche) Engines verwendet
2. Indexe fehlen entweder ganz oder sind teilweise fehlerhaft

Allgemein sieht die Source zwar etwas besser aus als beim letzten Mal, in der Summe ist es aber immer noch viel zu wenig. Genauso der Server. Einen so konfigurierten Server haben wir lange nicht mehr gesehen.

Weiterhin anmerken kann man noch, dass sich der Tracker offenbar nicht um unsere Security-Reviews schert. Beim letzten Review wurden wir anschließend zwar von Logitech kontaktiert, aber man hatte dort erwartet, dass wir ihnen die Arbeit abnehmen und sagen wie wir eingedrungen sind. Ein solches Vorgehen ist natürlich völliger Unsinn, weil damit das Grundproblem nicht gelöst wird. Die Kommunikation ist dann auch irgendwann von BC Reloaded Seite im Sand verlaufen. Nach unserer Ankündigung zu den TOG-Reviews ist BC Reloaded einer der wenigen Tracker, der sich nicht bei uns gemeldet hat. Wir hätten erwartet, dass hier zumindest ein grundlegendes Interesse an einer Wiedergutmachung von 2016 besteht.

Da BC Reloaded schon bei unserem letzten Review ihre User unzureichend informiert hat, haben wir das Zepter dieses Mal selbst in die Hand genommen und allen BC Reloaded Benutzern eine entsprechende E-Mail mit Informationen zukommen lassen.

tl;dr: Keinerlei Verbesserung des Zustands im Vergleich zum letzten Security-Review von 2016 und wieder krachend durchgefallen.

[Violence]

Besser wäre es nen Account für Rebound einzurichten, ihn testen zu lassen und dann erst für alle zu öffnen
bevor ihr es zum 3ten Mal vergeigt!

[sebastian1]

Besser wäre es nen Account für Rebound einzurichten, ihn testen zu lassen und dann erst für alle zu öffnen
bevor ihr es zum 3ten Mal vergeigt!

Er hat doch einen Acc-- ohne hätte er ja nicht seinen Test machen können!
Wir lasen ja wie ich es ja bereits erwähnte einige Sicherheitstester auf die Seite und ich werde mich, sobald ich das OK habe dann direkt an Rebound wenden.

EDIT/ Die Seite ist natürlich über die alte URL bereits wieder sichtbar

[g33rtz]

Doch wieder mit der alten Source.

Warum die lange Downzeit ??? das hätte man auch anderes lösen können oder ist die UNIT3D Source zuschwer für eueren Coder.

Wenn das der silaz aus dem NV Forum ist und wenn man seine Beiträge von früher mal liest dann hat er auch wirklich keine Ahnung.

[Bluesteel]

Das ist doch mal eine Gute Information, testet eure Source und den server aber vorher schon ausreichend. Kleiner Tip zur absicherung php.ini disabled_function.

---------- Post Merged at 13:55 ---------- Previous Post was at 13:52 ----------

Und selbst wenn es die alte source ist solang die bugs und Lücken gefixt sind spricht doch nichts gegen eine Verwendung!!!

[tom_tom]

Hallo zusammen,

ich finde das andauernde gebashe und gerante eher kontraproduktiv... Ich habe keine Befindlichkeiten zu bc oder anderen Trackern. Letztlich war es der Thread, den ich zum Einen tatsächlich vom Anfang bis zum Ende gelesen habe, zum Anderen gab es eine prägende Bemerkung im Review, weshalb ich es nun hier schreibe und nicht anderswo. Es würde vermutlich in jeden anderen "unsafe"-Thread ebenso gut passen.

Teils sehr amüsant, teils einfach nur traurig, mit einer großen Portion Ego.
Meine Meinung. Sie muss niemanden gefallen und keiner muss sie teilen.

Und wenn ich solche Beiträge lesen:

[...]bevor ihr es zum 3ten Mal vergeigt!

Kommt mir vieles wieder hoch... es gibt einige solcher unqualifizierter Aussagen, zu unterschiedlichen Sourcen, Trackern was auch immer, in diversen Threads. Ich fürchte das diese Leute selber nicht coden können, aber irgendwie der Meinung sind, sie könnten es bewerten, beurteilen und letztlich verurteilen. Irgendwie schade, wenn ihr mich fragt. Sollten Sie es aber fachkundig bewerten können, entschuldige ich mich natürlich.

Daneben gibt es Diskussionen über "Datensicherheit" und "Schutz"... Leute, euch ist aber schon klar, das dass Nutzen sowie das Betreiben eines Trackers zum Verteilen von Raubkopien und urheberrechtlich geschützten Werken illegal ist, oder?
Ich dachte mir, ich erwähne es noch einmal, da es scheinbar nicht allen klar zu sein scheint.
Und der Dealer um die Ecke wird mit Sicherheit kein Stoff in Krankenhausqualität mit TÜV-Siegel verticken, sorry ¯\_(ツ)_/¯

Aber weiter im Text.

Und was willst du uns damit sagen... Das Euer Coder keine Eier in der Hose hat sich selber um die Probleme zu lösen jemand anderen vorschiebt.
Also ehrlich man hatte 3 Jahre Zeit um es zufixen und habt es nicht hinbekommen und dann auf eine neue Source zuwechseln wo euer Coder wahrscheinlich auch keine Ahnung hat wie man mit der umgeht.
Wäre euer Coder zb zu Rebound gegangen und hätte sachlich gefragt nach den Bugs dann wären die heute schon geschlossen.
Man sieht und hört Dich nur schreiben sonst keinen anderen im Team der sich äusert.

Der Autor sollte vielleicht noch einmal lesen, was vorher geschrieben wurde, denn wie Rebound selber schreibt und auch an anderer Stelle sagte:

[...]
Wir haben schon mit vielen Trackerbetreibern zusammengearbeitet und bei Sicherheitsfragen oder nach Security-Reviews geholfen. Ob sowas funktioniert, liegt in erster Linie am Tracker und deren Staff. Wir geben keine Lücken raus, aber wir geben Tipps, Verbesserungsvorschläge und führen auch intern erneute Überprüfungen durch. Dies geschieht sehr oft unter dem Radar, da kein Tracker gerne öffentlich zugibt, mit uns zusammengearbeitet zu haben. Das ist für uns auch kein Problem und wir behandeln solche Kommunikation stets vertraulich. Man sollte einfach nur in einer angemessenen Form kommunizieren können. Einige Zeitgenossen sind dazu aber einfach partout nicht in der Lage und dann lehnen wir Kooperationen auch mal ab.
[...]

Was ich persönlich zwar absolut gar nicht nachvollziehen kann, aber sei es drum. Nach eigener Aussage, geht es, dir Rebound bzw. euch, um die Sicherheit der Tracker bzw. die Sicherheit der Nutzerdaten. Dann zu sagen, man käme immernoch in das System ohne mitzuteilen, wie man es gemacht hat, steht dem Gedanken meines Erachtens entgegen. Sag den Betreibern doch einfach wo die Probleme sind, bzw wie deine Exploits aussehen, im besten Fall, stell eine Möglichkeit bereit, das sie es selber testen können (Testautomatisierung o.ä.). Ich musste an ein kleines Kind denken, das sich freut und immer wieder sagt "ha ha, du bist doof, weil du es nicht findest und ich sags dir nicht, hihihi". Hilft meiner Annahme nach kein Stück bei der Lösung, bzw der Behebung.

Ist das üblich in dieser Szene? Jeder macht sein Ding und scheißt auf die anderen? Später aber noch ein paar Zeilen dazu.

Um noch kurz auf das Thema "Sicherheit" zu kommen, ihr bewegt euch in einem rechtlich sehr umstrittenen Bereich. Sowohl der Betrieb einer solchen Platform, als auch das ungefragte Hacken von Websiten steht unter Strafe.
Das aber nur am Rande.

Ich bin und so wird es wohl auch immer bleiben, der Auffassung, wenn man Sicherheitslücken findet, sollte man die Betreiber möglichst detailliert darüber informieren. Das in dieser Source Fehler sind, zeigt das Review von Rebound ja deutlich: (mit ein paar Notizen meinerseits)

Betriebssystem: Linux, Debian 8
Aktuell ist die Version 9.8. Ich kenne nun nicht die Minor Version des Systems, sollte aber nicht allzuweit von 8.11 entfernt sein, falls doch sollte man nach Möglichkeit ein Update machen oder zumindest händisch patchen.

Webserver: Apache
Wäre nicht meine erste Wahl, aber jeder nach seiner Fasson.

SSH: OpenSSH 6.7p1 Debian 5+deb8u7
Die aktuell Version ist auch hier weiter: OpenSSH 8.0/8.0p1 und beinhaltet sicherheitsrelevante Fixes, sollte auch gemacht werden.

PHP Version: 5.6.40-0+deb8u1
Diese Version wird seit 10.07.2016 nicht mehr supported. Aktuell ist die Version 7.3. Ich weiß aus eigener, leidvoller Erfahrung, das ein Umstieg von 5.6 auf 7.0 nicht ganz trivial ist, aber aus vielerlei Gründen sinnvoll. Sollte man ggf ins Auge fassen.

MySQL: 5.5.62
Etwas in die Jahre gkommen, sehe es aber häufiger noch im Einsatz. Aktuell ist MySQL irgendwo bei 8 (wie bei PHP hat man zwischen Versionen übersprungen, kommt wohl gerade in Mode)

OpenSSL: 1.0.1t
Die aktuelle Version ist schon weiter (1.1.1b) und in dem Minor Release Zyklus kam das letzte Update Anfang 2019.


Zusammenfassend, das ist meine Meinung, vermute ich die Ursache der veralteten Versionen in der Source selber. Soweit ich mich erinnere, ist die NV schon etwas in die Jahre gekommen, durch viele Hände gelaufen und egal wie viele dort draußen betrieben werden, gleicht keine der anderen. Gemeinsamkeiten sind mit Sicherheit vorhanden, aber eben nicht identisch.

Dann noch eine kleine Frage zu diesem Ausspruch:

Weiterhin anmerken kann man noch, dass sich der Tracker offenbar nicht um unsere Security-Reviews schert. Beim letzten Review wurden wir anschließend zwar von Logitech kontaktiert, aber man hatte dort erwartet, dass wir ihnen die Arbeit abnehmen und sagen wie wir eingedrungen sind. Ein solches Vorgehen ist natürlich völliger Unsinn, weil damit das Grundproblem nicht gelöst wird.

Aus welchem Grund wäre es "völliger Unsinn" mitzuteilen, wo die Lücke ist wenn?
Ich nehme mal einfach an, das alle die sich mit solchen Themen befassen so etwas wie lernen mussten. Lernen mit Büchern, Vorlesungen, Schulstunden, Forenbeiträgen und sonstigen Quellen. Alles Quellen, in denen Menschen ihr Wissen preisgeben, damit andere besser werden können. Alles andere empfinde ich als sehr egozentrische Sichtweise.


Mein Fazit
So gut ich das Reviewen von Systemen auch finde, vielleicht sollten alle gemeinsam an einem Strang ziehen. Nach dem was ich gelesen habe, denke ich, das sich keine Seite von aller Schuld freisprechen kann (ich hab aber auch keine Ahnung, was im direkten Kontakt lief).
Soweit ich weiß, gibt es kaum bis keine gewerblichen Betreiber solcher Plattformen, es ist also Freizeit die aufgebracht wird, ein solches System aufzubauen und zu betreiben und es wird mit privaten Mitteln finanziert oder über "Spenden" getragen.
Warum einige der Meinung sind, Ansprüche hinsichtlich Verfügbarkeit stellen zu können, ist mir völlig schleierhaft. Freut euch lieber, das es Menschen gibt, die das Risiko, auf sich nehmen, so etwas zu betreiben.
Und wenn es euch nicht passt, liest sich so, als gäbe es viele Alternativen.

Dieses Review macht nur eines, es denunziert die Betreiber/den Coder und exponiert den Tracker. Nichts weiter. Wäre es dem Author wichtig, eine Verbesserung herbeizuführen, sollte er Unterstützung anbieten und dabei spreche ich nicht von Hilfe á la "ändere $asd in der Datei xyz.php Zeile 768 in $qwe" sondern schlicht durch Mitteilung der gemachten Schritte, die zu den Exploits führten.
Würde zumindest eine schnelle Lösung herbeiführen. Denn der Hinweis "irgendwo auf der XYZ-Seite gibt es einen Exploit" hilft bei dem Spaghetti-Code der NV wohl nicht weiter.

Zudem ist die Aussage das ein System "safe" ist absolut Subjektiv und keinesfalls die Absolution vor dem Herren, sollten das einige denken.
Die korrekte Aussage wäre wohl: "Wir konnten keine Sicherheitslücken finden" und nichts weiter, denn vielleicht können es andere, die tiefer graben.

Daneben scheint das "finden" eines Coders offenbar ein Problem darzustellen, vielleicht sollten sich einfach mal die Betreiber der NV Sourcen zusammensetzen und gemeinsam die Probleme lösen, anstatt im stillen Kämmerchen zu werkeln. Übrigens ein Modell das auch Global sehr gut funktioniert, ihr wisst schon, Kommunikation und Ressourcen-Bündelung um ein gemeinsames Ziel zu erreichen.

Just my 2 cents

[uk501]

Kurz und schmerzlos!

Danke, da bin ich mit ALLEM was du sagst 100% bei dir!

[Instab]

Was ich persönlich zwar absolut gar nicht nachvollziehen kann, aber sei es drum. Nach eigener Aussage, geht es, dir Rebound bzw. euch, um die Sicherheit der Tracker bzw. die Sicherheit der Nutzerdaten. Dann zu sagen, man käme immernoch in das System ohne mitzuteilen, wie man es gemacht hat, steht dem Gedanken meines Erachtens entgegen.

ja, das sieht auf den ersten blick so aus. in der praxis allerdings hat sich das etwas anders entwickelt. zum einen nahmen die ansrpüche einiger tracker ziemlich zu was den "service" unsererseits angeht, und zum anderen waren hilfestellungen teilweise sehr mühsam, da die verantwortlichen keinerlei technische kenntnisse hatten.
da eine kurze info wo das problem liegt so gut wie nie ausreichend war, sind wir aus zeitgründen dazu übergegangen in der regel keinen "support" mehr anzubieten.

Sowohl der Betrieb einer solchen Platform, als auch das ungefragte Hacken von Websiten steht unter Strafe

wodurch sich das mehr oder weniger egalisiert

OpenSSH 6.7p1 Debian 5+deb8u7
Die aktuell Version ist auch hier weiter: OpenSSH 8.0/8.0p1 und beinhaltet sicherheitsrelevante Fixes, sollte auch gemacht werden.

das gibt es aber nicht für debian 8 sofern man nur die standardpakete in betracht zieht. für 8 ist im moment 6.7p1 5+deb8u8 aktuell und auch unter LTS gewartet. daher geht ssh in diesem fall in ordnung.

PHP Version: 5.6.40-0+deb8u1
Diese Version wird seit 10.07.2016 nicht mehr supported.

das ist doppelt falsch. zum einen erschien 5.6.40 am 10.01.2019 und zum anderen pflegen diverse linux und unix variaten ihre pakete zum teil selbst. rhel/centos beispielsweise kommen standardmäßig mit 5.4, welches sie selbst auf dem stand halten.
die aktuelle version für debian 8 ist 5.6.40+dfsg-0+deb8u2, was wie auch alles andere für debian 8 nach wie vor unter LTS gewartet wird. daher geht auch php in diesem fall in ordnung.

Aus welchem Grund wäre es "völliger Unsinn" mitzuteilen, wo die Lücke ist wenn?
Ich nehme mal einfach an, das alle die sich mit solchen Themen befassen so etwas wie lernen mussten. Lernen mit Büchern, Vorlesungen, Schulstunden, Forenbeiträgen und sonstigen Quellen. Alles Quellen, in denen Menschen ihr Wissen preisgeben, damit andere besser werden können. Alles andere empfinde ich als sehr egozentrische Sichtweise.

auch hier stimme ich dir zu. das setzt allerdings voraus, daß die betroffenen auch lernen wollen. leider war das fast nie zu erkennen.

Zudem ist die Aussage das ein System "safe" ist absolut Subjektiv und keinesfalls die Absolution vor dem Herren, sollten das einige denken.
Die korrekte Aussage wäre wohl: "Wir konnten keine Sicherheitslücken finden" und nichts weiter, denn vielleicht können es andere, die tiefer graben.

das ist zu simpel. 100% sicher gibt es nicht, also muß man sich fragen wo man die grenze zieht.
unsere reviews sollen unbedarften mitgliedern helfen zu sehen, welche seiten nicht offen wie ein scheunentor sind, was leider häufig der fall ist. differenzierte aussagen helfen dieser zielgruppe wenig, sie wollen nur wissen wo sie sich mehr oder weniger unbesorgt aufhalten können und wo nicht.
der sicherheitsfaktor, daß torrent tracker dieser art sich bestenfalls in einem rechtlichen graubereich bewegen, fließt in unser "safe" nicht mit ein. bei unseren reviews geht es nur um die technik.

[tom_tom]

ja, das sieht auf den ersten blick so aus. in der praxis allerdings hat sich das etwas anders entwickelt. zum einen nahmen die ansrpüche einiger tracker ziemlich zu was den "service" unsererseits angeht, und zum anderen waren hilfestellungen teilweise sehr mühsam, da die verantwortlichen keinerlei technische kenntnisse hatten.
da eine kurze info wo das problem liegt so gut wie nie ausreichend war, sind wir aus zeitgründen dazu übergegangen in der regel keinen "support" mehr anzubieten.

Kann ich nachvollziehen und stimme dir zu. Es liegt beim Betreiber sich um die Behebung zu kümmern, aber dann sollte man ihm, technisches Wissen hin oder her, zumindest die Lücken aufzeigen. Wie und ob er es dann behebt, zeigt sich dann ja in einem ggf. weiteren Review würde ich annehmen.

das gibt es aber nicht für debian 8 sofern man nur die standardpakete in betracht zieht. für 8 ist im moment 6.7p1 5+deb8u8 aktuell und auch unter LTS gewartet. daher geht ssh in diesem fall in ordnung.

das ist doppelt falsch. zum einen erschien 5.6.40 am 10.01.2019 und zum anderen pflegen diverse linux und unix variaten ihre pakete zum teil selbst. rhel/centos beispielsweise kommen standardmäßig mit 5.4, welches sie selbst auf dem stand halten.
die aktuelle version für debian 8 ist 5.6.40+dfsg-0+deb8u2, was wie auch alles andere für debian 8 nach wie vor unter LTS gewartet wird. daher geht auch php in diesem fall in ordnung.

Ok, dann waren meine Infos/mein Kenntnisstand veraltet. Sorry dafür.

auch hier stimme ich dir zu. das setzt allerdings voraus, daß die betroffenen auch lernen wollen. leider war das fast nie zu erkennen.

Ist schade, wenn man die Möglichkeit bekommt zu lernen und sie nicht ergreift. Obgleich ich mir vorstellen kann, das eine ungefragte Prüfung und Veröffentlichung das Verhältnis von vorne herrein in ein nicht unbedingt produktives Licht rückt.

das ist zu simpel. 100% sicher gibt es nicht, also muß man sich fragen wo man die grenze zieht.
unsere reviews sollen unbedarften mitgliedern helfen zu sehen, welche seiten nicht offen wie ein scheunentor sind, was leider häufig der fall ist. differenzierte aussagen helfen dieser zielgruppe wenig, sie wollen nur wissen wo sie sich mehr oder weniger unbesorgt aufhalten können und wo nicht.
der sicherheitsfaktor, daß torrent tracker dieser art sich bestenfalls in einem rechtlichen graubereich bewegen, fließt in unser "safe" nicht mit ein. bei unseren reviews geht es nur um die technik.

Für diese Zielgruppe, ist das vermutlich wirklich die beste Option. Auch wenn ich mir vorstellen kann, das eine differenzierte Aussage für einige Betreiber auch hilfreich sein kann.

[Rebound]

Kann ich nachvollziehen und stimme dir zu. Es liegt beim Betreiber sich um die Behebung zu kümmern, aber dann sollte man ihm, technisches Wissen hin oder her, zumindest die Lücken aufzeigen. Wie und ob er es dann behebt, zeigt sich dann ja in einem ggf. weiteren Review würde ich annehmen.

Hier muss man etwas mehr differenzieren. Als wir 2015 mit diesen Reviews angefangen haben, haben wir die Betreiber vor den Reviews häufig noch kontaktiert und detaillierte Informationen über diese Lücken weitergegeben. Aber es hat sich schnell herausgestellt, dass das wenig zielführend war.

Erstens ist es häufig schwierig die richtigen Verantwortlichen auf den Trackern überhaupt zu erreichen, weil die deutschen Tracker selten IRCs oder andere externe Kommunikationsmöglichkeiten anbieten. Teamspeak ist für uns eher ungeeignet und umständliche Kontaktaufnahmen über irgendwelche E-Mail-Formulare kosten uns viel Zeit und oft erhält man nie eine Antwort. Ich denke da immer wieder gerne an die Anekdote, die wir mit dem Betreiber von Borgzelle damals im TS hatten zurück (siehe https://www.sb-innovation.de/showthr...l=1#post328901).

Zweitens fehlt vielen Betreibern oft das technische Verständnis, um unsere Beschreibungen und Anleitungen zu den Lücken überhaupt zu verstehen und nachvollziehen zu können. Instab hat das bereits angesprochen. Das direkte Aufzeigen der Lücken birgt außerdem noch eine weitere, sehr große Gefahrenquelle: Der Betreiber schließt die Lücke, es gibt aber noch andere, die wir vielleicht gar nicht gefunden haben. Es ist schon mehrfach vorgekommen, dass von uns weitergegebene Lücken geschlossen wurden, wir ein halbes Jahr später aber andere gefunden haben. Viele Betreiber sind faul und tun nur das absolut Notwendige. Wenn wir sagen, da ist eine Lücke in der Datei xy, dann wird die geschlossen und davon ausgegangen, dass der Rest des Codes sicher ist. Das ist ein häufiger Trugschluss, den wir nicht unterstützen können.

Was auch immer wieder vergessen wird: Das ist hier ein kostenloser Service, der in erster Linie für die User und nicht die Betreiber existiert. Jedes Review kostet viele Stunden Zeit, wird aber oftmals als selbstverständlich hingenommen. Bestenfalls muss man sich dann auch noch von Leuten wie hier dem BCR-Team beschimpfen lassen.

Dass wir eine Art Bildungsauftrag haben ist uns klar und dem kommen wir im Rahmen unserer Möglichkeiten nach. Dieser Bildungsauftrag beinhaltet aber eben nicht, dass wir den Leuten die Arbeit abnehmen (dann könnten wir es ja auch gleich selber machen). Wer einen Tracker betreiben möchte, ist verpflichtet und verantwortlich, die Sicherheit auf eben diesem sicherzustellen. Wir helfen bei angemessener Kommunikation gerne und haben dies in der Vergangenheit auch bereits unzählige Male getan. Traut sich in der Öffentlichkeit allerdings niemand zuzugeben, was nebenbei bemerkt sehr schade ist.

Auch wenn ich mir vorstellen kann, das eine differenzierte Aussage für einige Betreiber auch hilfreich sein kann.

Die gibt es, bei entsprechender privater (und vor allem freundlicher) Kontaktaufnahme zu uns. Es wäre von uns sehr fahrlässig, wenn wir die Exploits im Review mitveröffentlichen würden. Das würde den Trackern nämlich noch zusätzlich schaden, wenn dann Trittbrettfahrer in der Lage wären, ebenfalls Daten zu entwenden. Mehr als einmal gab es billige Versuche von unbeteiligten Dritten, Informationen zu den Lücken von uns zu erhalten. Und solche Leute haben damit nicht so gute Absichten wie wir.


Letztendlich sind wir nicht der Feind. Die meisten Betreiber haben dies inzwischen erkannt und streben oft schon im Vorfeld eine Zusammenarbeit mit uns an. Das ist gut und wenn man sich den schlechten sicherheitstechnischen Standard so anguckt, auch bitter notwendig. Es gibt immer noch einige die dazu nicht in der Lage sind, sei es weil sie sich persönlich in ihrer Ehre verletzt sehen oder weil sie glauben, wir würden hier irgendwelche Privatfehden austragen.
Wer mit uns angemessen kommuniziert, wird auch immer eine angemessene Antwort erhalten. Wer das nicht kann oder will, darf sich hinterher nicht beschweren.

[tom_tom]

Hier muss man etwas mehr differenzieren. Als wir 2015 mit diesen Reviews angefangen haben, haben wir die Betreiber vor den Reviews häufig noch kontaktiert und detaillierte Informationen über diese Lücken weitergegeben. Aber es hat sich schnell herausgestellt, dass das wenig zielführend war.

Finde ich schade, also sowohl das es nicht zielführend war, als auch das ihr damit aufgehört habt die Exploits weiterzugeben.

Zweitens fehlt vielen Betreibern oft das technische Verständnis, um unsere Beschreibungen und Anleitungen zu den Lücken überhaupt zu verstehen und nachvollziehen zu können. Instab hat das bereits angesprochen. Das direkte Aufzeigen der Lücken birgt außerdem noch eine weitere, sehr große Gefahrenquelle: Der Betreiber schließt die Lücke, es gibt aber noch andere, die wir vielleicht gar nicht gefunden haben. Es ist schon mehrfach vorgekommen, dass von uns weitergegebene Lücken geschlossen wurden, wir ein halbes Jahr später aber andere gefunden haben. Viele Betreiber sind faul und tun nur das absolut notwendige. Wenn wir sagen, da ist eine Lücke in der Datei xy, dann wird die geschlossen und davon ausgegangen, dass der Rest des Codes sicher ist. Das ist ein häufiger Trugschluss, den wir nicht unterstützen können.

Was auch immer wieder vergessen wird: Das ist hier ein kostenloser Service, der in erster Linie für die User und nicht die Betreiber existiert. Jedes Review kostet viele Stunden Zeit, wird aber oftmals als selbstverständlich hingenommen. Bestenfalls muss man sich dann auch noch von Leuten wie hier dem BCR-Team beschimpfen lassen.

Nichts anders habe ich geschrieben/gesagt (falls es anders rüberkam, sorry). Instab sagte es sehr treffend:

das ist zu simpel. 100% sicher gibt es nicht[...]

Was du auch unterstreichst. Nichts destotrotz sollten die gefundenen und vorhandenen Lücken doch geschlossen werden, oder nicht?
Ich erinnere mich an einen ehemaligen Kollegen der zu sagen pflegte "Wer lange genug sucht wird etwas finden, immer!" und was den Bereich IT Sicherheit betrifft würde ich meinen, das es zutrifft.
Versteh mich bitte nicht falsch, aber wenn ihr kein Review macht, gehen die Leute doch ebenso davon aus, das dass System sicher ist, oder übersehe ich etwas?

Ich persönlich finde es auch super, das ihr das macht. Mir fehlt dazu die Keativität die Lücken zu finden, die nicht offensichtlich sind und es sollte keineswegs als selbstverständlich verstanden werden, da stimme ich dir zu.

Dass wir eine Art Bildungsauftrag haben ist uns klar und dem kommen wir im Rahmen unserer Möglichkeiten nach. Dieser Bildungsauftrag beinhaltet aber eben nicht, dass wir den Leuten die Arbeit abnehmen (dann könnten wir es ja auch gleich selber machen). Wer einen Tracker betreiben möchte, ist verpflichtet und verantwortlich, die Sicherheit auf eben diesem sicherzustellen. Wir helfen bei angemessener Kommunikation gerne und haben dies in der Vergangenheit auch bereits unzählige Male getan. Traut sich in der Öffentlichkeit allerdings niemand zuzugeben, was nebenbei bemerkt sehr schade ist.

Erm, ok ich würde es nun nicht unbedingt als Bildungsauftrag beschreiben , eher als eine "Informationsauftrag" oder so. Ich stimme dir aber auch voll und ganz zu, das einen Fehler zu finden in keinster Weise seine Behebung beinhaltet. Wie ich sagte, lediglich informieren, wo und was dazu führte.
Das es keiner Zugibt, ich würde es auf die Ellenbogenmentalität schieben, was nicht bedeutet das es schade ist, das es keiner macht. Wie ich in meinem Post schon schrieb, wäre es sicher hilfreich, wenn sich die Leute, zumindest technisch zusammentun würden, aber naja, bin da vielleicht zu sehr Idealist.

Die gibt es, bei entsprechender privater (und vor allem freundlicher) Kontaktaufnahme zu uns. Es wäre von uns sehr fahrlässig, wenn wir die Exploits im Review mitveröffentlichen würden. Das würde den Trackern nämlich noch zusätzlich schaden, wenn dann Trittbrettfahrer in der Lage wären, ebenfalls Daten zu entwenden. Mehr als einmal gab es billige Versuche von unbeteiligten Dritten, Informationen zu den Lücken von uns zu erhalten. Und solche Leute haben damit nicht so gute Absichten wie wir.

Letztendlich sind wir nicht der Feind. Die meisten Betreiber haben dies inzwischen erkannt und streben oft schon im Vorfeld eine Zusammenarbeit mit uns an. Das ist gut und wenn man sich den schlechten sicherheitstechnischen Standard so anguckt, auch bitter notwendig. Es gibt immer noch einige die dazu nicht in der Lage sind, sei es weil sie sich persönlich in ihrer Ehre verletzt sehen oder weil sie glauben, wir würden hier irgendwelche Privatfehden austragen.
Wer mit uns angemessen kommuniziert, wird auch immer eine angemessene Antwort erhalten. Wer das nicht kann oder will, darf sich hinterher nicht beschweren.

Das ist der Teil, wie erwähnt, zu dem ich nichts sagen kann und werde. Da hab ich keine Ahnung von, wie und was da abgeht in privaten Gesprächen. Ein freundlicher Ton sollte aber immer möglich sein, denke ich zumindest.
Das ihr die Exploits nicht öffentlich macht, finde ich ebenso gut und wenn es wirklich so schwierig ist, es den Betreibern mitzuteilen... joa blöd :/ Sollte aber IMHO egal sein, wer dort im Team die Info bekommt wie und wo Lücken sind, denn alle sollten ein Interesse daran haben sie zu schließen.
Sonst einfach eine Text-Datei auf dem System ablegen mit allen Infos und darauf verweisen

Wie gesagt, ich finde es gut, das ihr das macht, leider sind einige Reviews sehr denunzierend. Vielleicht gab es eine Vorgeschichte (du hattest BCR angesprochen) oder der Kontakt begann unfreundlich. Aber es sind ja alles nur Menschen.

tl;dr
Ich finds gut das ihr das macht und würde mich freuen, wenn mir jemand sagen würde, wo Lücken sind :-) Weiter so!

P.S. bei zu vielen Rechtschreibfehlern... Sorry, bin auf dem Sprung zum Essen

[Rebound]

Was du auch unterstreichst. Nichts destotrotz sollten die gefundenen und vorhandenen Lücken doch geschlossen werden, oder nicht?

Selbstverständlich ist es auch unser Anliegen, dass die Lücken geschlossen werden und die Trackern den Usern ein sicheres Zuhause bieten.
Aber die "Lücken" von denen wir hier reden, sind jetzt keine komplexe Mathematik oder benötigen jahrelange Berufserfahrung. Wir reden hier von wirklich simplen Fehlern im Code, die absolut vermeidbar sind. Jeder der sich mit diesem Thema 30 Minuten beschäftigt hat, weiß genau wonach er gucken muss und wie man solche Lücken verhindert.
Dass wir es trotzdem immer wieder schaffen, zeigt leider, wie schlecht der Bildungsstand bei den Verantwortlichen von solchen Trackern ist oder die Bereitschaft, sich entsprechendes Wissen anzueignen.

Ich erinnere mich an einen ehemaligen Kollegen der zu sagen pflegte "Wer lange genug sucht wird etwas finden, immer!" und was den Bereich IT Sicherheit betrifft würde ich meinen, das es zutrifft.

Das kann man erstens so pauschal nicht sagen und zweitens ist es in diesem Fall nicht zutreffend. Wir nutzen unsere jahrelange Erfahrung mit solchen Webprojekten, um nach gängigen und oftmals sogar jahrelang bekannten Lücken zu suchen. Dies geschieht zum Teil durch automatisierte Tests, zum Teil durch ein paar Manuelle. Wir setzen uns nicht hin und suchen solange, bis wir irgendwann mal etwas finden. Dafür ist uns unsere Freizeit dann doch zu schade.
Wer durch diese Tests durchfällt, der hat seine Hausaufgaben einfach nicht gemacht. Die Gründe dafür sind in diesem Fall erst mal zweitrangig.

Versteh mich bitte nicht falsch, aber wenn ihr kein Review macht, gehen die Leute doch ebenso davon aus, das dass System sicher ist, oder übersehe ich etwas?

Wir schreiben den Leuten nicht vor wovon sie auszugehen haben. Aber bei der Vielzahl deutscher Tracker, ist es mit unseren Kapazitäten einfach unmöglich alle zu überprüfen. Wenn man etwas zwischen den Zeilen liest oder sich die Reaktionen der Betreiber anschaut, erkennt man aber auch recht schnell, wo man kompetente Leute findet und welche Projekte man lieber meiden sollte.

Ich glaube außerdem auch, dass ich mich nicht zu weit aus dem Fenster lehne wenn ich behaupte, dass unsere Arbeit der letzten Jahre durchaus dazu beigetragen hat, dass Trackerbetreiber für das Thema Sicherheit sensibilisiert wurden und sich die allgemeine Sicherheit auf den Trackern spürbar erhöht hat.

Für konstruktive Kritik sind wir immer offen. Leider gibt es selten solche gut reflektierten Beiträge wie die von dir. Die Betreiber die wissen was sie tun, kommen nicht in eine solche Situation wie sie BCR nun zum zweiten Mal durchlebt, deshalb ist das Bild was sich hier teilweise abzeichnet nicht unbedingt der Realität entsprechend. Auch wenn man durchaus sagen kann, dass das allgemeine Niveau deutscher Tracker sehr weit unten anzusiedeln ist. Dies betrifft aber bei weitem nicht nur die technischen Aspekte (die wir ja ausschließlich im Rahmen unserer Security-Reviews beleuchten).

[Instab]

Wer lange genug sucht wird etwas finden, immer

Wer durch diese Tests durchfällt, der hat seine Hausaufgaben einfach nicht gemacht

um das noch ein bisschen zu verdeutlichen:

wir machen hier keineswegs super-raffinierte angriffe, die sachen wie z.b. assembly oder adressmanipulation voraussetzen. ganz im gegenteil, die lücken die wir meist finden und nutzen sind erschreckend trivial. seiten die bei uns durchfallen haben wirklich komplett versagt.

leider sind einige Reviews sehr denunzierend

eine webseite vernünftig abzusichern ist im vergleich zu "richtigen" programmen kaum der rede wert, daher können wir in solchen fällen guten gewissens den verantwortlichen jegliches technische können absprechen. das ist logischerweise nicht sehr schmeichelhaft aber angebracht.

[F1r3st0rm]

Vielen Dank an tom_tom für seine Posts. Das waren Themen die mich selbst schon lange interessiert haben und auch danke an Instab und Rebound dass ihr auch so ausführlich drauf geantwortet habt. Zum Thema ihr gebt keine Lücken raus. Das finde ich weiterhin schade. Ich sehe es genauso wie ihr, dass man keine Schritt für Schritt Lösungen geben sollte, aber zumindest die Art des Angriffes sollte genannt werden (was die Betreiber mit der Info dann machen ist dann deren Sache). Aber ich fände es schon fair wenigstens zu sagen, wir sind z.B. mittels XSS oder SqlInjection reingekommen. Für euch sollte das kein großer Aufwand sein und ein fähiger Coder sollte dann zumindest einen Anhaltspunkt haben, wie ihr rein gekommen seid. Also falls ihr das nicht sowieso schon tut, dann wäre das zumindest sehr wünschenswert.

Was die Informationspolitik von BC angeht muss ich allerdings den anderen hier zustimmen. Das haben andere Projekte erheblich besser gelöst. Auch das öffentliche Hin und Her Wechseln der Source lässt mich ein wenig Nachdenklich zurück. Es ist viel falsch gelaufen, allerdings finde ich es dennoch eine Frechheit, was sich manche User hier rausnehmen. Vor allem die Anfeindungen Sebastian gegenüber halte ich für vollkommen überzogen. Er ist nicht der Coder und kann daher für die Sicherheitslücken am wenigsten.

[Rebound]

wie ihr, dass man keine Schritt für Schritt Lösungen geben sollte, aber zumindest die Art des Angriffes sollte genannt werden (was die Betreiber mit der Info dann machen ist dann deren Sache). Aber ich fände es schon fair wenigstens zu sagen, wir sind z.B. mittels XSS oder SqlInjection reingekommen. Für euch sollte das kein großer Aufwand sein und ein fähiger Coder sollte dann zumindest einen Anhaltspunkt haben, wie ihr rein gekommen seid. Also falls ihr das nicht sowieso schon tut, dann wäre das zumindest sehr wünschenswert.

Genau das tun wir doch bereits von Anfang an?
Aber selbst mit diesen Informationen, können die wenigsten Verantwortlichen damit etwas anfangen.

[unodue]

BC ist wieder Online seit SONNTAG.

Laut Tracker News aber noch in Testphase.

Mal schauen wie es wird. Noch ist ja kein erneuter - SECURE REVIEW - erfolgt.