Category Archives: Security

Neues Mitglied im TLS 1.3 Verweigererclub: The Boeing Company

Posted on by

Für die nachfolgende Betrachtung eines TLS Verweigerers wäre es günstig, wenn Ihr das hier gelesen habt:

SMTP: pphosted.com trifft auf moderne SSL-Technik

ProofPoint Hosted hat seine Probleme schon vor einer Weile behoben, aber wie heute bekannt wurde, haben wir im TLS 1.3 Verweigerer Club ein prominentes neues Mitglied: The Boeing Company 

Genau die Firma, wo dauernd Teile von den Flugzeugen und Raumschiffen abfallen 🙂 Im Gesamtbild betrachtet ergibt das ja dann auch irgendwie Sinn 😉

Jetzt kann ich viel behaupten, also Beweise her: Aufgenommen Heute, 29.5.2025 12:0x Uhr

1. Die Mailserver ermitteln

$ dig mx boeing.com

; <<>> DiG 9.18.33 <<>> mx boeing.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34226
;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;boeing.com. IN MX

;; ANSWER SECTION:
boeing.com. 86400 IN MX 10 phx-mbsin-02.mbs.boeing.net.
boeing.com. 86400 IN MX 10 phx-mbsin-01.mbs.boeing.net.
boeing.com. 86400 IN MX 10 clt-mbsin-04.mbs.boeing.net.
boeing.com. 86400 IN MX 10 clt-mbsin-03.mbs.boeing.net.
boeing.com. 86400 IN MX 10 clt-mbsin-02.mbs.boeing.net.
boeing.com. 86400 IN MX 10 clt-mbsin-01.mbs.boeing.net.
boeing.com. 86400 IN MX 10 ewa-mbsin-04.mbs.boeing.net.
boeing.com. 86400 IN MX 10 ewa-mbsin-03.mbs.boeing.net.
boeing.com. 86400 IN MX 10 ewa-mbsin-02.mbs.boeing.net.
boeing.com. 86400 IN MX 10 ewa-mbsin-01.mbs.boeing.net.
boeing.com. 86400 IN MX 10 phx-mbsin-04.mbs.boeing.net.
boeing.com. 86400 IN MX 10 phx-mbsin-03.mbs.boeing.net.

2. einige davon auf TLS 1.3 testen

# openssl s_client –connect clt-mbsin-01.mbs.boeing.net.:25 -starttls smtp -tls1_3
Connecting to 130.76.144.154
CONNECTED(00000003)
80322E30907F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:909:SSL alert number 40
—
no peer certificate available
—
No client certificate CA names sent
—
SSL handshake has read 370 bytes and written 265 bytes
Verification: OK
—
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
—

# openssl s_client –connect ewa-mbsin-02.mbs.boeing.net:25 -starttls smtp -tls1_3
Connecting to 130.76.20.187
CONNECTED(00000003)
80B27B732E7F0000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:ssl/record/rec_layer_s3.c:909:SSL alert number 40
—
no peer certificate available
—
No client certificate CA names sent
—
SSL handshake has read 370 bytes and written 301 bytes
Verification: OK
—
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
—

3. beweisen, daß wir stellvertretend mit einem davon TLS 1.2 reden können:

(verkürzte Ausgabe, das Cert brauchen wir nicht in Hexlesen können )

# openssl s_client –connect phx-mbsin-04.mbs.boeing.net:25 -starttls smtp -tls1_2
Connecting to 130.76.184.173
CONNECTED(00000003)
depth=2 C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
verify return:1
depth=1 C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
verify return:1
depth=0 C=US, ST=Illinois, L=Chicago, O=The Boeing Company, CN=phx-mbsin-04.mbs.boeing.net
verify return:1
—
Certificate chain
0 s:C=US, ST=Illinois, L=Chicago, O=The Boeing Company, CN=phx-mbsin-04.mbs.boeing.net
i:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 7 00:00:00 2024 GMT; NotAfter: Aug 12 23:59:59 2025 GMT
1 s:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 24 00:00:00 2020 GMT; NotAfter: Sep 23 23:59:59 2030 GMT
2 s:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Aug 1 12:00:00 2013 GMT; NotAfter: Jan 15 12:00:00 2038 GMT
—
Server certificate
…
subject=C=US, ST=Illinois, L=Chicago, O=The Boeing Company, CN=phx-mbsin-04.mbs.boeing.net
issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
—
Acceptable client certificate CA names
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256:RSA+SHA224:ECDSA+SHA224
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, prime256v1, 256 bits
—
SSL handshake has read 5183 bytes and written 395 bytes
Verification: OK
—
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: F851762BA22AB5420F8B567A8497D6C5A23EE86984316B6D69A52DC89D50EC90
Session-ID-ctx:
Master-Key: 8F769C7F3910F70E26288F83282A84CBB4C598F041A0D84017AD96978582D48E616D7AFF8AC250E471A9354CEBBF53F8
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 1 (seconds)
TLS session ticket:
0000 – 81 13 9b c2 a5 94 8a cf-64 42 b4 b5 bd 33 9d 63 ……..dB…3.c
0010 – a0 08 c2 78 9f 07 ef 54-53 bd 80 35 4d 7d 8c 44 …x…TS..5M}.D
0020 – 38 ab 14 3d 4a 56 df 7e-d6 5d 9e a4 46 a8 02 0b 8..=JV.~.]..F…
0030 – 50 5d 9e 4c 85 53 2d 4c-4e 12 e9 3d 87 43 4d 78 P].L.S-LN..=.CMx
0040 – 46 e4 6b cb fd 30 71 8d-fe 4c 8a 7f 3f 21 1f 1e F.k..0q..L..?!..
0050 – 46 3a 40 02 79 07 ca 65-dd b7 50 3f 91 4b ff 7f F:@.y..e..P?.K..
0060 – 91 3b 26 78 97 44 f7 cb-11 a4 9e 31 0c e7 06 9b .;&x.D…..1….
0070 – 4f d1 da c6 32 b8 6e 3e-3e d9 40 31 02 17 99 45 O…2.n>>.@1…E
0080 – 29 3e 17 82 9e a4 ed ab-f6 e2 c7 49 c4 43 0d a9 )>………I.C..
0090 – c1 fb 21 3b 05 cb 4f 96-76 49 02 5b 54 92 0b 03 ..!;..O.vI.[T…
00a0 – 80 19 d8 08 cc 6a 40 63-a3 02 9b 78 17 a1 d8 2e …..j@c…x….
00b0 – 26 91 85 1e ee 7d 5f 4c-f5 a5 69 2b b1 52 a5 51 &….}_L..i+.R.Q

Start Time: 1748512677
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
—
250 HELP

QED.

Das könnte der neue Slogan sein: „Boeing – digital wie analog veraltet“ 😉

 

Qualys: Drei Umgehungen von Ubuntus Namespace-Beschränkungen für unprivilegierte Benutzer

Posted on by

Gestern Abend kam ein Advisory von Qualys über Sicherheitsprobleme mit Ubuntus AppArmor und UserNameSpaces heraus. Das Ubuntu Security Team ist von Anfang an involviert, ob das aber per Update gefixt werden kann, ist fraglich. Bevor Panic ausbricht, damit das überhaupt relevant wird, muß ein Dritter, egal ob legal oder per Remote-Exploit ( z.b. durch Firefox ) Zugriff auf Euren PC haben.

Qualys: Drei Umgehungen von Ubuntus Namespace-Beschränkungen für unprivilegierte Benutzer

Erst mal klären wir, das es mit Namespaces auf sich hat. Dateibeschränkungen für User sind Euch ja sicher bekannt, da regelt man, welcher User auf welche Datei zugreifen darf bzw. diese ausführen kann. Das reichte irgendwann nicht mehr aus, als alle Pcs Netzwerkkarten und andere schöne Geräte wie USB, PCI hatten, denn der Zugriff da drauf war nicht beschränkt, weil Root die eingerichtet hat. In einem NameSpace sind bestimmte Rechte wie z.b. Netzwerkänderungsrechte möglich. Das ist aber nur ein Recht unter Dutzenden.

Kleines Beispiel:

ap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

Das sind die Adminrechte des Systemaccounts für Fedora, also der Hauptuser, abgesehen von Root. Deswegen sind auch Admin Capabilities enthalten. Der „Otto-Normal“-Benutzer hat diese i.d.R. nicht, weil er z.b. kein neues Interface zum Netzwerk hinzufügen soll. Nützlich ist das z.b. für User-VPNs, daher braucht eine Anwendung die VPN Tunnel bauen will und vom User ausgeführt wird, die Rechte dazu, was in dem Namespace organisiert ist. Damit kann jeder Benutzer eines PCs den NetworkManager starten und sich ein VPN einrichten ohne das man Root sein muß oder sudo etc. braucht.

Das System wurde von Qualys ausgetrickst, weil Ubuntu das selbst ausgehöhlt hatte:

Bei Ubuntu 24.04 LTS ist dann die Verwendung von unprivilegierten Benutzernamensräumen für alle Anwendungen erlaubt, aber der Zugriff auf alle zusätzlichen Berechtigungen innerhalb des Namespaces verweigert worden. Dies ermöglicht mehr Anwendungen feingranuliert mit dieser Standardbeschränkung umzugehen, während gleichzeitig gegen den Missbrauch von Benutzer-Namensräumen geschützt, ergibt sich aber eine zusätzliche Angriffsfläche für den Zugriff auf den Linux-Kernel.“ Zitat: übersetztes Qualys Security Advisory 27.3.2025 via FD ML

Meint nichts anderes als das die Maßnahme unabsichtlich ein Tor zur Hölle, in dem Fall zur Local Privilege Escalation, aufgestoßen hat. Ganz nach dem Motto: der Weg zur Hölle ist mit guten Absichten gepflastert 😉

Diese drei Wege hat Qualys gefunden:

– Ein unprivilegierter lokaler Angreifer kann einfach das Tool aa-exec verwenden (das standardmäßig auf Ubuntu installiert ist), um zu einem der vielen vorkonfigurierten AppArmor-Profile zu wechseln, die die Erstellung von Benutzernamensräumen mit vollen Funktionen erlauben (z. B. das Chrome-, Flatpak- oder Trinity-Profil).

– Ein unprivilegierter lokaler Angreifer kann zunächst eine Busybox-Shell ausführen, die standardmäßig auf Ubuntu installiert ist und zu den Programmen gehört, deren vorkonfiguriertes AppArmor-Profil die Erstellung von Benutzernamensräumen mit vollen Fähigkeiten erlaubt. Namespaces mit vollen Fähigkeiten erlaubt.

– Ein unprivilegierter lokaler Angreifer kann eine Shell mit LD_PRELOAD in eines der Programmen, deren vorkonfiguriertes AppArmor-Profil die Erstellung von die Erstellung von Benutzernamensräumen mit vollen Fähigkeiten erlaubt (z. B. ist Nautilus standardmäßig auf Ubuntu Desktop installiert).

Zitat: übersetztes Qualys Security Advisory 27.3.2025 via FD ML

Qualys sagt aber auch, daß die meistens gar nicht nötig sind, weil die Linux Distributionen Tools zur Verfügung stellen um NameSpaces mit vollen Rechten zu erstellen. Der Unterschied ist, daß das eine gewollt ist, das andere nicht. Im weiteren behandelt das Advisory die Möglichkeiten innerhalb eines beliebigen NameSpaces auszubrechen und sich Adminrechte zu verschaffen, der eigentliche Exploit um den es dabei geht.

Qualys zeigt im weiteren Verlauf des Advisories konkrete Beispiele wie das geht und bespricht diese. Was es am Ende nicht gibt, ist eine Lösung sich davor zu schützen.

Das Advisory findet Ihr im Netz hier: https://seclists.org/fulldisclosure/2025/Mar/8

Hallo Web.de, bitte Hirn einschalten!

Posted on by

Liebes Web.de Entwickler-Team,

einfache Logik ist nicht eurer Ding, oder?

Wenn Ihr eine Email bekommt, die eine FROM: und TO: Mailadresse hat, die gleich ist UND KEIN SMTP-AUTH im Spiel ist, dann nennt man das SPAM!

From: <name@web.de>
To: <name@web.de>
Subject: Sie haben eine offene Rechnung. Bitte begleichen Sie Ihre Schulden so schnell wie m=?UTF-8?B?w7ZnbGljaA==?=

Und was macht man mit Spam? Man nimmt sie nicht an. Ihr dagegen, sendet die Delivery Message über die Nichtzustellung der Spam einfach an das Opfer! Wie blöde ist das denn bitteschön?

From: "WEB.DE Mailer Daemon" <mailer-daemon@web.de>
Subject:  Mail delivery failed: returning message to sender
To: <name@web.de>

Wie kann das nur sein, daß die Spam angenommen, aber auch abgelehnt wurde?

Naja, weil zwei Mailserver daran beteiligt waren: a) der web.de Mailserver und b) unser Mailserver, dem das Postfach weitergeleitet wird.

Unserer war es auch, der die Spam abgelehnt hat, denn Web.de hat sie nicht als Spam erkannt 😀

Dabei war das ganz leicht, weil es ein massiver Spamausbruch war:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error.

The following address failed:

    meinwebdepostfach@meinedomain.de:
        SMTP error from remote server for RCPT TO command, host: resellerdesktop.de (83.246.67.243) reason: 550-rejected because 82.165.159.4 is in a black list at zen.spamhaus.org
550 Listed by SBL, see https://check.spamhaus.org/sbl/query/SBL594406

Sonst hätte Spamhaus die IP nicht auf der Liste.

Ich fasse mal zusammen:

Der alte Trick mit Absender=Empfänger geht bei Web.de einfach so durch, obwohl das leicht als Betrug erkennbar ist, weil macht man normalerweise nicht und wenn man das machen würde, dann müßte man sich zum Senden authentifizieren ( SMTP-AUTH ), was aber eine ext. eingelieferte Email von einem Spammer nicht macht. Hmmm… was ist dann das Kriterium…?… ach ja richtig: fehlendes SMTP-AUTH!!!!

Noch einmal ganz leicht:

SMPT-AUTH + mein web.de Absender =  GUT
kein SMPT-AUTH + mein web.de Absender =  SCHLECHT!!!!!!!!!!!!!!!!!!!!!!

Und jetzt ab ins Körbchen mit Euch, Ihr Web.de-Schafe! 😀