RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Es ist vielleicht nicht das schlechteste, daß Mozilla seine Leute rausgekantet hat, denn je weniger da arbeiten, desto weniger können so richtig tief in die Scheiße greifen 🙁

RCE: 68.8< Firefox Mobile <80.x Schwachstelle

Wie gestern Abend von den Hacker News  berichtet wurde, gibt es im FireFox Mobile eine so gravierende Sicherheitslücke, daß sich einem die Fußnägel aufrollen. Wenn man mit einem FF M < Version 80 gemeinsam in einem WLAN oder anderen Netz ist, kann man dem Firefox eine Nachricht senden, und er führt das direkt aus: Eine Remote Code Execution Schwachstelle.Die Schwachstelle wurde im FireFox Mobile 80 für Android gefixt.

Hinweis: In einem FF Mobile 68.8 konnte das Verhalten, trotz absichtlicher Aktivierung des Features nicht reproduziert werden.

FireFox sendet SSDP Pakete ins Netz um Geräte zu finden, die man als Screencast verwenden kann. Das wäre a) der Job vom OS und b) nicht so schlimm, wenn man das Ergebnis, das einem unaufgefordert jeder im Netz senden kann, mal auf SINNVOLLE Werte prüfen würde, statt es BLIND auszuführen.

Über so einen Intent kann man auch Addons oder andere Apps Installieren’und natürlich auch Webseiten mit Exploits besuchen, das macht es so gefährlich.

Kleines Demo gefällig?

Dies Video stammt von Gitlab-Account des Red Teams:

Wer sich mit Android Programmierung nicht auskennt, ein „Intent“ ist eine Anfrage von App A an (meistens) alle anderen Apps, ob die mit dem Inhalt was anfangen können. So brauche ich bspw. als Browser keinen Videoplayer integrieren, weil das eine andere App vermutlich viel besser kann als ich.

Aber selbstverständlich nehme ich als Anwendung dazu keine Infos, die selbst von einer dubiosen anderen Stelle im Netz bekommen habe, sondern leite da nur Sachen hin, die „ich selbst“ erstellt oder runtergeladen habe vom Ziel.

So ein Verhalten ist grob fahrlässig und eines Anfängers ohne Security Schulung würdig, aber doch nicht den Entwicklern eines Marken-Browsers.

Fußnote

NetFlix Mobile scheint auch per SSDP nach Sachen zu suchen, aber ob die Entwickler den gleichen dicken Bug eingebaut haben, ist nicht bekannt. Wer selbst nachsehen will, soltle in seinem WLAN mal das hier starten: „sudo tcpdump -A -n not tcp and not icmp and port ssdp“

SSDP ist das Simple Service Discovery Protocol und gehört als UDP basiertem Dienst zum UPnP, den Universal Plug & Play. Diese ganzen Autodetect Sachen sind als Funktion ganz nett, aber führen immer mal wieder zu Schwachstellen. Per UPnP kann man z.b. als Programm der Firewall sagen, daß man gern ein Loch haben würde für seinen Dienst, ohne das der Firewall-Admin was davon mitbekommt. Wird oft von Instant-Messengern benutzt um durch die DSL-Router zu kommen.

Shitrix is back : Citrix ADC – Mehrere Schwachstellen

Gerade erst ist jemand in Düsseldorf an den Folgen einer schlecht gewarteten Installation von Citrix ADC gestorben, da hat Citirix die nächste Sicherheitslücke für uns parat.

Shitrix is back : Citrix ADC – Mehrere Schwachstellen

Wie das BSI Cert mit Stand 18.9. 2020 mitteilt, sind von einer Privilegien Eskalation folgende Produkte betroffen:

Citrix Systems ADC < 11.1-65.12,
Citrix Systems ADC < 12.1-58.15,
Citrix Systems ADC < 12.1-FIPS 12.1-55.187,
Citrix Systems ADC < 13.0-64.35,
Citrix Systems Citrix Gateway < 13.0-64.35,
Citrix Systems SD-WAN < WANOP 10.2.7b, 
Citrix Systems SD-WAN < WANOP 11.1.2a,
Citrix Systems SD-WAN < WANOP 11.2.1a

Die dazu gehörigen CVE Nummern: CVE-2020-8245, CVE-2020-8246, CVE-2020-8247

Besonders prekär an der Sache:

Ein entfernter, –> anonymer <– oder authentisierter Angreifer kann mehrere Schwachstellen in Citrix Systems ADC, Citrix Systems Citrix Gateway und Citrix Systems SD-WAN ausnutzen, um einen Cross-Site Scripting Angriff durchzuführen, einen Denial of Service zu verursachen oder seine Rechte zu erweitern. Sprich: Jeder kanns. Man sehen ob die Uni Düsseldorf jetzt wieder 9 Monate braucht um gehackt zu werden: https://www.forschung-und-lehre.de/politik/hacker-haben-uniklinik-duesseldorf-erpresst-3110/

Ich frage mich immer, wieso Citrix Ihren Kram nicht einfach per Repo verteilt, das ist doch alles CentOS was die da nutzen.
Update: Es steht zu befürchten, daß die Uni Düsseldorf gar nicht durch die Januar Lücke gehackt wurde, sondern durch DIESE neue Lücke. Zeitlich paßt das, wenn die Hacker den Zero-Day hatten, bevor Citrix das überhaupt patchen konnte. Wenn man nämlich den offiziellen Bericht (s.o.) dazu durchliest, soll das bereits im Januar gepachted und auch geprüft worden sein. Wenn das stimmt, kann es eigentlich nur diese neue Lücke oben sein. Bin mal echt gespannt 😀
Update 20.9.2020:
Der Mailserver der Universitätsklinik Düsseldorf ist noch nicht wieder erreichbar. Gemerkt habe ich das nur, weil ich denen die CVEs zu den neuen ADC Lücken geschickt habe, wir dürfen gespannt sein.

 

TLS: Timing Attacke RACCOON

Intel kennt das Problem: Laufend kommt einer an und kann an der Laufzeit von Berechnungen Daten ableiten, die er nicht sieht. Jetzt ist mal wieder TLS dran mit so einem Angriff auf den DH Schlüssel.

TLS: Timing Attacke RACCOON

Wie die Hacker News berichten, gibt es eine neue, aber sehr spezielle, Methode an einen Serverschlüssel zu kommen. Voraussetzung ist allerdings, daß der Server seine verwendeten Schlüssel erneut benutzt. Das sollte er wegen PFS sowieso nicht tun, aber nicht alle Dialekte von TLS 1.2 sind PFS fähig.

Um die Lücke ausnutzen zu können, muß der Angreifer zu dem sehr präzise Messungen zur Laufzeit machen können, daher muß er technisch sehr dicht am Server dran sein, um die Messungen akkurat vornehmen zu können. In den meisten Fällen wird der Versuch da bereits scheitern. Auch Scheitern wird der Angriff, wenn PFS zum Einsatz kommt, weil der Server den privaten DH Schlüssel dann nicht wieder verwendet.

F5, Mozilla, Microsoft und OpenSSL haben schon Updates parat, wobei M$ sich darauf beschränkt, die DHE einfach abzuschalten, statt das Problem zu lösen 😀 Auch ne Methode 😉 Wie man hier nachlesen kann: OPENSSL: https://www.openssl.org/news/secadv/20200909.txt hat OpenSSL das Problem in älteren OpenSSL Versionen bereits durch eine andere Defaulteinstellung behoben. Damit ist die Gefährlichkeit des Angriffs eher gering einzuschätzen.

Ich habe mir mal die Mühe gemacht und konnte selbst in einer 2 Jahre alten OpenSSL Version den nötigen Cipher nicht und damit ist der Webserver auch nicht anfällig. Ein Test durch SSLLabs hat das bestätigt:

Uses common DH primesNo, DHE suites not supported
DH public server param (Ys) reuseNo, DHE suites not supported
ECDH public server param reuseNo

Also, keine Panik, wenn Ihr nicht 10 Jahre alte Software einsetzt, ist alles gut.

LUKS: Wie man einen Cloud-Container erstellt.

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der  anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich),  kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem.  Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD )  macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks

WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.

Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

CryptSetup: Update behebt CVE-2020-14382

Hi,

wer von Euch LUKS2 einsetzt sollte jetzt weiterlesen und nebenbei schon mal schauen, ob die Updates eingespielt sind.

CryptSetup: Update behebt CVE-2020-14382

CryptSetup fällt auf manipulierte Dateien herein, die sich als Luks2 Container ausgeben. Möglich ist es, damit ein nicht vorgesehenen Schreibzugriff auszulösen. Das ist per se nicht gut für Eure Datenintegrität 😉

Behoben wurde die in Version 2.2.0 eingeführte Ursache mit dem Update auf 2.3.4.

Nicht betroffen ist, wer Luks nicht benutzt um manipulierte Datencontainer aufzumachen aka. nicht auf alles draufklicken, was per Post kommt 🙂

Problematisch wird das nur, wenn jemand einen manipulierten USB Stick bei Euch einschieben kann, der sich als LUKS2 Laufwerk ausgibt. Da solche Laufwerke automatisch eingebunden werden, wird der Container sofort geöffnet. Hier hilft USB-Guard weiter, der nicht autorisierte USB Geräte gar nicht erst an das OS lässt.

Updates für Fedora gibts z.B. so:

sudo dnf update https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-2.3.4-1.fc31.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/cryptsetup/2.3.4/1.fc31/x86_64/cryptsetup-libs-2.3.4-1.fc31.x86_64.rpm

Quelle: https://access.redhat.com/security/cve/CVE-2020-14382

Schwachstellen im Apache Webserver < 2.4.44

Wer Apache als Webserver einsetzt, sollte jetzt aufpassen, denn wir haben jeweils eine  RCE und eine DOS Schwachstelle.

Schwachstellen im Apache Webserver < 2.4.44

In Apache wurden drei Schwachstellen identifiziert und im August behoben. Leider hat man u.a. bei Fedora vergessen, das publik zu machen, deswegen hier die Erinnerung für Euch:

Im HTTP2 Modul sind zwei Schwachstellen enthalten, die zum Crash führen und damit als DOS (Denial of Service) gelten:

important: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-9490)
moderate: Push Diary Crash on Specifically Crafted HTTP/2 Header (CVE-2020-11993)

Beide Schwachstellen kann man auch per Konfigurationsänderung abwehren, falls man keine gepatchten Webserver bekommen kann, oder noch nicht hat:

Je nachdem was Ihr für eine Distro habt, wird HTTP2 an verschiedenen Stellen aktiviert. Bei Fedora bietet sich an, eine eigene kleine Config in conf.modules.d/ anzulegen. In die Datei kommen zwei Einträge:

99-mitigate-http2.conf:

H2Push off
LogLevel warn mod_http2.c:error

Dann mit „systemctl httpd restart“ den Server neustarten. Die erste Anweisung behebt die 2020-9490 und die zweite sagt dem HTTP2 Modul, es soll nur kritische Sachen loggen, anstatt auch Warnungen. Das ist wichtig, da Angreifer über einen provozierten Fehler den Logging-Pool der Prozesse stören können und das führt dann zum Crash, was aber nur geht, wenn der Fehler auch geloggt wird.

moderate: mod_proxy_uwsgi buffer overflow (CVE-2020-11984)

Wer mit dem WebSocket Proxy uwsgi arbeitet, der muß updaten, eine Mitigation der möglichen Remote-Code-Schwachstelle ist nicht möglich. Bis zum Update kann man das Modul auch abschalten:

Für Fedora wäre das hier in conf.modules.d/00-proxy.conf:

# LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

Einfach ein # vor die Ladeanweisung und den Webserver mit „systemctl httpd restart“ neustarten. Natürlich funktionieren die Proxy Tunnel, die auf „uwsgi:://server:port/uri“ lauten, dann nicht mehr. Habt Ihr noch einen vhost konfiguriert, der das benutzen möchte, wird der Start des Webservers nicht funktionieren.

Updates vorhanden

Updates auf die 2.4.46 liegen für Fedora bereit. Für alle, die Ihre Server per Autoupdate versorgen, hat sich das Problem damit bereits erledigt.

Spammer sind so blöd, das schreit förmlich nach einer eigenen Meisterschaft

Vor ein paar Tagen erreichte uns ja diese Phisingmail mit dem Docx Anhang eines Dienstes, mit dem wir unmöglich in Verbindung stehen können: Aber natürlich will ich wissen, was für ein Docx da auf mich wartet! . Die Geschichte geht in die 2. und 3. Runde, und das … gleichzeitig \o/

Spammer sind so blöd, das schreit förmlich nach einer eigenen Meisterschaft

Zeitgleich liefen heute zwei Emails ein, die alle „von uns“ wären und „an uns“ gesendet wurden 😉 Klar, wir sind komplett schizo und wissen nicht was wir uns so mailen, besonders in einer uns „fremden“ Sprache 😀

Mail 1:

Betreff: Hello info@{eineunsererdomains} your email server is temporarily blocked, kindly verify urgently to avoid closurel

Email server indicates that your mail server account has low security verification, this means that sending and receiving of mail messages for your mail server has been temporarily blocked until a verification process has been done. Therefore you MUST verify your mail server account to avoid the termination of the mail server access.<br><br>Kindly click below to sign in and verify your mail account and we will help you take the corrective action automatically.

Kindly click below to sign in and verify your mail account and we will help you take the corrective action automatically.

<hier ein Link zu einem Redirekt auf eine Fake-Seite eines mir völlig unbekannten Dienstes>

Once you have verified your mail server account, the verification process will beupdated automatically

Mail 2:

Empfänger: sales@iqbal-gloves.com
Betreff: Shutdown Notice For info@{eineunsererdomains}

We received your instruction few hours ago to terminate your email info@{eineunsererdomains} account on our server!

Your email will be terminated in: 1:13:36 seconds

[Dicker Button „Stop this action Now!“] [Dicker Button „Ignore warning & shutdown Email“]

Wie Ihr sehen könnt, gehören die oder der eine Phisher zur absoluten Elite und würden die Meisterschaft im Phishen total dominieren 😀  „1:13:36 seconds“ die Typen sind sooooo blöde 😀 Die Links auf den klickbaren Elementen der HTML Email gehen alle zu dem komischen Redirectservice ct.sendgrid.net . Wird Zeit, die URL bei Spamassassin in den Filter einzufügen, die Jungs nerven nur noch 🙂

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.

Aber natürlich will ich wissen, was für ein Docx da auf mich wartet!

Aber natürlich will ich wissen, was für ein Docx da auf mich wartet!

Klaro, und ich bin natürlich blöd genug auf den Link zu klicken, damit der Verbrecher weiß, daß die Adresse gelesen wird 🙂

Wem sowas hier ins Haus flattert …

 Microsoft Docx Portal Notifier for info@{eineunsererdomains.de} Mail. 
 
   
RECEIVED: 3/3 pages scanned file awaits your review on info@{eineunsererdomains.de} Microsoft Docx

<a href=“http://uxxxxxxxxx.ct.sendgrid.net/ls/click?upn=MÜLLENTFERNT!“> REVIEW NOW: </a>

by {eineunsererdomains.de} Microsoft Document Portal

direkt in die digitale Mülltonne damit! Wer nur den Absender sieht, so sieht sowas aus.
From: "{eineunsererdomains.de} Microsoft Docu Portal" <ainal@satextilesourcing.com>
To: info@{eineunsererdomains.de}
Subject: 3/3 Pages New Document.

Leicht zu erkennen, daß das nicht von M$ ist und da „wir“ gar nicht mit Windows arbeiten, werden „wir“ natürlich auch nicht das „Online“ Docu Portal von M$ benutzen, oder Ihr etwa??? 😉

Mozilla: welche 250 Mitarbeiter entlassen wurden

Moin,

wenn man dem Twittergerücht ( mehr ist es imho nicht ) glaubt, wurden Teile des Security Teams von Mozilla vor die Tür gesetzt. Andere Twitteruser wiederum melden sich als „unser Gecko Team“ hats geschafft und auch andere Bestandteile hätten sich da zu Wort gemeldet.

Mozilla: welche 250 Mitarbeiter entlassen wurden

Kann irgendwer von denen beweisen, daß er dort arbeitet oder gearbeitet hat? Ich weiß es nicht.

Wenn man das so liest und es für bare Münze nimmt, wundert es nicht wirklich, was da so in den letzten Versionen von Firefox rausgekommen ist. Das ist kein einheitliches Produkt, das ist eine Ansammlung von Bestandteilen.

Und um diesem Beitrag die nötige inhaltliche Kontroverse zu geben:

Scheiße, war der FireFox gestern effektiv 😀

Das muß ich kurz erklären. Gestern Abend war Meet Jitsi VideoConf der BSLUG. Ich sahs unten mit dem Tablet und hatte mit Chromium daran teilgenommen. Nach rund 38 Minuten waren nur noch 54 % Akkuladung vorhanden, die CPU Frequenz der 4 Kerne lag dauerhaft bei 2.2 GHz, was ohne Turbo die größtmögliche Einstellung ist und mit dem größten Stromverbrauch gleichzusetzen ist. Keine 20 Minuten später waren es nur noch 15 %.

Im Top nachgesehen lief Chromium als einziger Prozess mit voller Last. Daraufhin habe ich den beendet und die VC mit Firefox weiter gemacht und siehe da, die Last ging runter. FF hat ~40% weniger Energie für die gleiche Leistung verbraucht als Chromium ( Freeworld Build von RPMFusion ).

Jetzt wärs schön rauszubekommen wieso das so war, weil der Chromium-Freeworld damit wirbt, HW Unterschützung zu haben. Das wird i.d.R. mit mehr Leistung pro Watt im der Verbindung gebracht, ergo weniger CPU Leistung und Energieverbrauch, als ohne HW Unterstützung.

Um den Schluß mit oben zu bekommen, ich hoffe nicht, daß sie die Energieoptimierungsexperten rausgeworfen haben, weil die haben nachweislich was geleistet 😉