Hmm, instead of securing their networks and pushing for better security standards they'll cut access to one fish. Is that an ideal strategy? Some other bigger meaner fish will still use those vulnerabilities.
I was wondering if the GSMA is or should regularly perform security audits.
https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
Or perhaps award publicly visible badges of honor to those mobile networks that are not vulnerable to similar attacks.
I mean how many companies do we know? that publicly stated: Hello our mobile users btw. we fixed those vulnerabilities in our network! You should now be better protected.
I never got any such information from any of my providers. Did you?
Beste Grüsse, Regards si s-auzim de bine
Florin Sfetea
On Friday, May 19, 2023, 12:00:21 PM GMT+2, <swinog-request(a)lists.swinog.ch> wrote:
Send swinog mailing list submissions to
swinog(a)lists.swinog.ch
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
swinog-request(a)lists.swinog.ch
You can reach the person managing the list at
swinog-owner(a)lists.swinog.ch
When replying, please edit your Subject line so it is more specific
than "Re: Contents of swinog digest..."
Today's Topics:
1. Re: Sicherheit von SS7 - mit Schweiz-Bezug (Ralph Krämer)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 May 2023 22:33:17 +0200 (CEST)
From: Ralph Krämer <ralph.kraemer(a)vable.ch>
Subject: [swinog] Re: Sicherheit von SS7 - mit Schweiz-Bezug
To: swinog <swinog(a)lists.swinog.ch>
Message-ID: <172298345.199.1684441997706.JavaMail.zimbra(a)vable.ch>
Content-Type: text/plain; charset=utf-8
nice : https://www.spiegel.de/netzwelt/netzpolitik/andreas-fink-mobilfunkverband-g…
about time ;-)
----- Am 15. Mai 2023 um 13:31 schrieb Florin Sfetea via swinog swinog(a)lists.swinog.ch:
> Hello all,
>
> I was reading this old(2018) ENISA Report [
> https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
> |
> https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
> ]
> Might help in some way but reading it had reminded me of ARP spoofing/poisoning
> attacks which even today are still used and work in a lot of networks that I
> have been. :)
>
> One year later I had open a case with Salt where I requested a public statement
> that they had fixed/mediated the issues discovered up to that time(March 2019)
> or at least that a remediation plan was in place.
>
> Someone from Support answered that " The introduction of 5G will only take place
> if data security is guaranteed for our customers and we can assume that the
> security issue will not lead to a delay in the introduction of 5G. "
>
> I was not satisfied ::)) with the answer and requested an escalation
>
> They eventually closed my case in July 2019 with:
>
> " Dear Sir,
>
>
> Salt follows industry best practices in terms of security for its entire mobile
> infrastructures and improves constantly the protection of its mobile
> infrastructures and customers. The case you mention is known and has been
> addressed accordingly.
> "
> No public statement nor such other mentions of which fix was exactly addressed.
>
> I don't have anything with any mobile provider. At that time it was just happen
> to be Salt. I move from time to time to different other ones.
>
> I think we should have here in Switzerland more or less a same similar to ENISA
> organization that should supervise and perform regular audits on mobile
> providers. Melani/NCSC would that fit your bill?
>
> I never really had time to further test if any of those vulnerabilities or newer
> where actually fixed. Someone should definitely do it. Free for fame or payed
> from a government branch is to
> [ https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
> | https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
> ]
>
>
> Regards,
> Florin
>
> _______________________________________________
> swinog mailing list -- swinog(a)lists.swinog.ch
> To unsubscribe send an email to swinog-leave(a)lists.swinog.ch
------------------------------
Subject: Digest Footer
_______________________________________________
swinog mailing list -- swinog(a)lists.swinog.ch
To unsubscribe send an email to swinog-leave(a)lists.swinog.ch
------------------------------
End of swinog Digest, Vol 219, Issue 11
***************************************
Hello all,
I was reading this old(2018) ENISA Report https://www.enisa.europa.eu/publications/signalling-security-in-telecom-ss7…
Might help in some way but reading it had reminded me of ARP spoofing/poisoning attacks which even today are still used and work in a lot of networks that I have been. :)
One year later I had open a case with Salt where I requested a public statement that they had fixed/mediated the issues discovered up to that time(March 2019) or at least that aremediation plan was in place.
Someone from Support answered that "The introduction of 5G will only take place if data security is guaranteed for our customers and we can assume that the security issue will not lead to a delay in the introduction of 5G."
I was not satisfied ::)) with the answer and requested an escalation
They eventually closed my case in July 2019 with:
"Dear Sir,
Salt follows industry best practices in terms of security for its entire mobile infrastructures and improves constantly the protection of its mobile infrastructures and customers. The case you mention is known and has been addressed accordingly.
"
No public statement nor such other mentions of which fix was exactly addressed.
I don't have anything with any mobile provider. At that time it was just happen to be Salt. I move from time to time to different other ones.
I think we should have here in Switzerland more or less a same similar to ENISA organization that should supervise and perform regular audits on mobile providers. Melani/NCSC would that fit your bill?
I never really had time to further test if any of those vulnerabilities or newer where actually fixed. Someone should definitely do it. Free for fame or payed from a government branch is to
https://www.gsma.com/security/gsma-mobile-security-research-acknowledgement…
Regards,
Florin
Hello
One of my clients got a problem to receive mails from one customer.
He sends mails from its system through isis.servercorner.net and the mailserver refuses to accept the mail with a «no such mailbox» answer.
But the mailserver should not look for the mailbox but forward to M365.
We suspect a wrong mx in the dns of servercorner.net.
When we look into the mx of the customer, it looks like:
dig mx 4plusarchitektinnen.ch +short
0 4plusarchitektinnen-ch.mail.protection.outlook.com.
dig 4plusarchitektinnen-ch.mail.protection.outlook.com +short
104.47.22.10
104.47.22.74
The customer was on a hosting somewhere inside servercorner.net and we suspect there are leftovers.
Anybody here from servercorner.net? How to contact?
Regards, Urs
(Resend von der richtigen Absender-Adresse)
https://www.haaretz.com/israel-news/security-aviation/2023-05-10/ty-article…
The Secretive Swiss Dealer Enabling Israeli Spy Firms
(…)
It leads from the Americas to Africa to South-East Asia, but also to Basel, a mediaeval town on the banks of the Rhine and the unassuming home of Andreas Fink, a Swiss telecom expert whose unusual skills have placed him at the centre of this industry.
(…)
reveal how Fink's systems have served as a conduit for probing and attacking phone networks across the globe
(…)
When contacted by this investigation, Fink admitted to working with companies and “legally entitled government agencies” as a provider of surveillance services.
(…)
Fink's request to Robert was for "SS7 access" and "a bunch of global titles". In other words, he wanted a list of phone numbers, belonging to Robert's phone company, which could be used to send queries to other networks in other countries.
(…)
--
Matthias Leisi
Katzenrütistrasse 68, 8153 Rümlang
Mobile +41 79 377 04 43
matthias(a)leisi.net <mailto:matthias@leisi.net>
Hi,
The IANA AS Numbers registry has been updated to reflect the allocation of the following blocks to APNIC:
151866-152889 Assigned by APNIC 2023-05-10
152890-153913 Assigned by APNIC 2023-05-10
You can find the registry at:
https://www.iana.org/assignments/as-numbers/
The allocation was made in accordance with the Policy for Allocation of ASN Blocks to Regional Internet Registries:
https://www.icann.org/resources/pages/global-policy-asn-blocks-2010-09-21-en
Best Regards,
Selina Harrington
IANA Operations Manager
G'day Franco,
To the partners at least, in October 2022 informing them that
anything containing digest-type 1 and/or key algorithm 5 oder 7 are no longer supported and will be deleted. This was done last week and digest-type 2 and key algorithm should be used.
Since end of January 2023 you could not use them anymore.
cheers
Marcus
Monday, May 1, 2023, 12:55:56 AM, you wrote:
>> Hey SWINOGgers,
>> I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for.
>> For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust.
>> However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not...
>> Is this a known problem?
>> Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have
>> to do with the algorithm being used.
>> Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement?
>> Random example, e.g. gkb.ch (notably a bank...)
>>> dig +short @dns1.inventx.ch gkb.ch dnskey
>>> 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55
>>> 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s=
>>>
>>> dig +short @a.nic.ch gkb.ch ds
>>>
>>> -> no DS record
>> Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256):
>>> dig +short @ns2.switch.ch switch.ch dnskey
>>> 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ==
>>> 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A==
>>> 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ==
>>>
>>> dig +short @a.nic.ch switch.ch ds
>>> 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C
>> Could anybody shed some light on this?
>> Thx & Gruass, Franco
>> _______________________________________________
>> swinog mailing list -- swinog(a)lists.swinog.ch
>> To unsubscribe send an email to swinog-leave(a)lists.swinog.ch
--
---------------------------------------------------
Klingon Embassy Runners
http://klingon-embassy-runner.im
*********************************************
Klingon Embassy:
http://www.klingon-embassy.co.za
---------------------------------------------------
-----------------------------------------------------
Hey SWINOGgers,
I noticed that DNSSEC was somehow auto-disabled at registry level for some .ch domains I am responsible for.
For these domains, no DS records are published anymore in the .ch zone, dnsviz shows a broken chain of trust.
However, registrar data still shows that DNSSEC is enabled, but the registry (SWITCH) says it is not...
Is this a known problem?
Seems not all DNSSEC protected .ch domains are affected, which leads me to the suspicion that it might have
to do with the algorithm being used.
Did SWITCH turn off older algorithms, e.g. algo 7 (RSASHA1-NSEC3-SHA1)? Did I miss an announcement?
Random example, e.g. gkb.ch (notably a bank...)
> dig +short @dns1.inventx.ch gkb.ch dnskey
> 256 3 7 AwEAAdYydDZyd5M3UGS5b4Yv6qlIO5eOSwskJ/DQjiRO0as59ZG6hMDJ VseqslJMTwghdiCrd/sicWvDOszK6Cuqye0+ZEm9tfG6gxgWWmzpSmXQ KDHRG1iV8UF0KSOciFAPp4qRe083KPXu2ChXkTUSAa/iRCcZdFJK2M6l c7Gjjj55
> 257 3 7 AwEAAbQv5Whc+cna1IbtESB+Pwx+8eP5jfbjhuqiFuU/18qUckR9NxT7 KUCT8GDlRTsGYmuKxcMITvH510CgGOA/6TORaB4iIXRnACmfiiku25/B NHmNJd58ymZ/ED17smVJ4ou77/rhxW+/0Q1iVIAOcY8EblWq3EabepYz E6CY9Vh/RTh2mvSl80h8nZyFotsEwN0LIlc/Pi0qGmy7iTOBqtVsbFVm gssn/2c7IMCA8N2aaP1it8Qi+3DDGDh3N8HSEIVk+nrgQtsqQaLOFPGQ Q0ezahQO6oVGKG4XAHw+2XaZQ3UT0sTcFj3ZVKCcGE4Ddoa3J/gqLQh7 aA44cVIQx+s=
>
> dig +short @a.nic.ch gkb.ch ds
>
> -> no DS record
Working example with algorithm 13 (ECDSA Curve P-256 with SHA-256):
> dig +short @ns2.switch.ch switch.ch dnskey
> 257 3 13 keJOWxnKOCymNa0sPpwp/ioeyvgrXjY9hu8KxWdaxlMFukxquKVLdt2J 5KxGOpmIZZbOXRALfG78FnDsE/k8EQ==
> 256 3 13 YOf+TLHGeDBL0q6DSpE4vE2ub8RUvniew7xYkZJHocU6je7Ww/MfUeHf B1LEDpFNFloYHFBvWD92gu5MT2ZJ1A==
> 256 3 13 twHlL7CfhxPadzuRi3wRxEDs+3i/oe9W3heRKiP8CALwpexBZYCjMJ2w Z403h9dJ/iA7CzCTSmvePLGdJ4cIzQ==
>
> dig +short @a.nic.ch switch.ch ds
> 32265 13 2 8A865736961D246F99D6111BCA060E69908380FD5545D799F21E4652 DA60A17C
Could anybody shed some light on this?
Thx & Gruass, Franco
