THEMA: waschzettel.at weg?

Hallo Torsten,

stimmt, die Seite wurde von AH betrieben und ein Zugangscode war nötig.
Frag AH selber was mit der Seite passiert ist, vielleicht meldet er sich auch hier zu Wort.

Roco Waschzettel bekommst du aber weitgehend auch über die Seite von Roco selber.

Gruß Detlef

Folks!
Der Server auf dem das WaschzettelWEB gehostet ist wurde geknackt und eine Randsomware hat die Dateien gekapert, also verschlüsselt. Es gibt mehrere Generationen Backups die sich nicht recovern lassen Das ist ein riesen Pech lag nicht in meiner Hand.

Der Angriff war ein BruteForce Weg. Irgend ein Account hatte ein zu schwaches Passwort. Ich hab' das nach etwa 2-3 Stunden bemerkt und den Server herunter gefahren um weiteren Schaden auch externen zu vermeiden. Passwörter waren Komplex (also das übliche groß/klein Zahlen keine Wörter udglm) aber erzwungen wurden nur 8 Zeichen oder mehr. Das ist heutzutage offensichtlich schon zu einfach.

Der Server der alles gehostet hat, auch meinen WEB Shop, ist inzwischen abgebaut und durch einen neuen ersetzt worden. Dabei wurde auch alle Dienste gleich auf aktuelle Versionen hochgezogen. Fast alle WEBs sind aus Backups recovered. Die Backups der SharePoint Datenbank gehen leider nicht, genau da ist ein Fehler drin. Ich hoffe daß es in den nächsten Monaten einen Crack für diese Verschlüsselung geben wird dann bringe ich das Waschzettelweb wieder hoch wie es war und spiele die inzwischen eingehenden Scans ein.

Sorry about...
-AH-

Danke für die Info - und viel Erfolg!!!

Beste MobaGrüße
Gerhard

>Die Backups der SharePoint Datenbank

SharePoint - den unausgegoren Mist sind wir in der Firma mittlerweile/größtenteils los, das hat selbst die IT eingesehen!

Gruß, Michael

Guten Morgen,

hatte mit Sharepoint noch nie zu tun und kann es nicht bewerten, aber ich denke das war eine schwere Mißkonfiguration verbunden mit zu komplizierter SW Lösung die zu viele Credentials braucht. Einfache in-memory Lösung wie z.B. SQlite wäre ausreichend - da die Website 7/24 läuft, würde ein einmaliges Einlesen der Directory Struktur und der Metadaten genügen. Bei Änderungen kann man diesen Prozess ja anwerfen. Es stört nicht einmal wenn das ein Request ist der exponiert ist. Der Angreifer kann maximal den Server zubomben, dann greift halt der DoS Schutz.
Telnet, ftp, Remote Desktop Ports und so Zeugs nach außen sperren dort wo die Files und die DB wirklich liegen, dann können die da draußen scannen, crawlen und hacken was sie wollen. Oder MS SQL, maysql, MariaDB benutzen - die PDF in Clob. Die Web App Maschine kriegt nur R/O auf die SQL, da fährt die Eisenbahn drüber. Sollte jemand den Web Server über eine Backdoor brechen und töten, ist der halt hin.
Tipp: Portscans von außen machen, Website auf Broken Links testen (verraten potentiellen Angreifern möglicherweise etwas über die Infrastruktur oder die Applikation) SQL Insertion (Joker, Exec, Queries) testen, und sowas wie die Default Seite gehört nicht ins www. Es soll möglichst nicht erkennbar sein was und welche Version auf der Kiste rennt.
PHP, ASPX, JSP etc. verschleiern.
Ich denke da erzähle ich sowieso nichts neues.
Hinterher ist gut gescheit reden.

Ich hatte einst bei einem großen Büromaschinen Hersteller das Problem, dass da das Backup immer brav gefahren wurde, bloß war kein einziges Band in dem Set lesbar...

Grüße, Peter W

Hi Peter!
Die üblichen Maßnahmen wir Ports verbiegen, Standard Account Namen abschalten und unnötigen Mist wie ftp gar nicht starten ist ohnehin gemacht gewesen und auch am neuen Server gemacht. Das Ding steht in der InterXion und hat einfach überaus immens gute Bandbreite um Angriffe drauf zu fahren.
Bei Zugängen werden die Parameter immer geprüft und sobald was unwahrscheinlich ist der Aufruf verworfen. Ich hab' so in der Minute etliche Versuche im Shop auf sendit.pl zuzugreifen um Menschen unbedingt nötige Verbesserungen von Körperteilen anzubieten, sowohl für Männlein als auch Weiblein . Kann ich schlecht abstellen irgendwie muß ja die Bestellung zu mir versendet werden. Der Einbruch ist auch nicht über die üblichen Angriffe auf die Datenbank Accounts erfolgt, die sind sofort nach der Installation umbenannt und "disablet" worden. Die Datenbank hat andere Accounts zum leben gehabt. Irgend einer meiner Kunden hat ein schwaches PW gehabt, und das war's dann auch schon.
Ganz interessant ist wie viele Versuche auf Port 3389 kommen, ständig obwohl das abgeschaltet ist - OK nicht wirklich geht aber in den Wald. Trotzdem werden da Wörterbücher aller Sprachen durchgeorgelt. Wenn's zu heftig ist dann sperre ich das Netzt aus dem der Angriff kommt, das geht automatisch. Warum das in dem Fall nix geholfen hat, der Angreifer kam aus Ägypten, muß ich auch erforschen.
Das wirklich Wesentliche an dem Fall ist daß die Backups defekt waren wir suchen wo der Fehler entstanden ist. Daten sind da aber inkonsistent schon seit Monaten.
-AH-

Hallo,



Wir führen es gerade ein Aber ich hab es geschafft - mit viel Voodoo und Opfergaben - die Sharepoints als Netzlaufwerk einzubinden. Da muss ich mir wenigstens die grauselige Bedienoberfläche nicht antun...



Das hab ich noch einen Zacken schärfer erlebt

Gut: Man richte ein Backup für den Fileserver ein.

Besser: Man nehme ein verschlüsseltes Backup und packe den Schlüssel brav in den Passwortmanager.

Richtig gut: Damit die Daten vom Passwortmanager nicht irgendwann mal weg sind, packt man sie auf das Netzlaufwerk und nicht auf die Festplatte vom Adminrechner.

Schlecht: Wenn man dann das Backup braucht und die Daten vom Passwortmanager im verschlüsselten Backup liegen... dessen Passwort man nicht weiß, weil es ja im Passwortmanager steht

Grüße,
Rico

Hi Arnold,

Danke für die Infos.

Ich habe auch schon bei der Wayback Maschine geschaut, die haben immerhin die Struktur (Spurweite / Hersteller) und die Metadaten zu Jahresbeginn einmal noch erfasst, nur die PDFs halt leider nicht.

Ägypten hätte ich jetzt nicht erwartet. Könnte aber auch eine Verschleierungstaktik sein.

Grüße, Peter W