7 ms·

The problem here is the ability to spoof caller ID. This should not be possible. Think of incoming CLID in the same way that you do email From: addresses. Oft

The problem here is the ability to spoof caller ID. This should not be possible. Think of incoming CLID in the same way that you do email From: addresses. Often and easily faked. Funnily enough both my office PBX and SMTP daemon check incoming CLID/HELO and drop attempts to spoof their own identity. Its not a particularly sophisticated protection these days but is one of many, many rules. Actually, now I come to think of it, my firewalls also check for inbound IP spoofing on their own IPs. As the OP stories highlight, your mental firewall must make you bail out when asked for your PIN, regardless of how legitimate things sound. The only thing that should ever request your PIN is a machine that you have stuffed your card in first. I'm pretty certain that CVV requests should also only ever come from vendors that you are buying from, not your bank.

coaxial 8y ago
Curious: how does the PBX verify caller ID? Do you know how it works in practice?
- gerdesj 8y ago
  It doesn't actually verify it, all it can do is read it. Just like email. When the PBX is told that the caller is say 01460223344 (I'm in the UK) then it would infer that the caller is from Crewkerne in Somerset due to the 01460 which is a designated area code. It may also be able to look up the whole number and infer a source. However, just like email the CLID can be trivially faked and just like email, the lookup in your contacts is then wrong and potentially dangerous. In the case of telephony, if you subscribe to the BT service (I presume it still exists) that will return a name given a CLID (just like DNS for a price!) then you may end up with completely the wrong thing on your display. Just to re-iterate the point: a PBX/phone/whatever cannot ... CANNOT ... verify CLID (Calling Line IDentification) it can only show what is presented to it. Remember this, please: CLID is nominally under the control of the caller and could also be changed in transit. It should absolutely NOT be considered authoritative in any way.
  - wlesieutre 8y ago
    It's not quite "Just like email" because email has systems in place to authenticate this, while phone systems do not. https://en.wikipedia.org/wiki/DMARC https://en.wikipedia.org/wiki/DMARC
    - gerdesj 8y ago
      Have you ever tried to implement DMARC? DKIM and SPF are OK but DMARC breaks mail lists. Yes there are ways to mitigate but it might not be worth it unless you also do DNSSEC as well. Well actually I believe that every little helps and use every weapon available. I do think that the analogy works really well. PBXs can have quite a few weapons of their own to attempt to authenticate callers. For example you can pass "anonymous" calls to a dialplan that gets the caller to identify themselves and then play that to the recipient who then gets to allow/disallow the call - basically make the (human) recipient part of the firewall. Also, PBXs that deal with VoIP can use IP rules just like a firewall to make decisions on what to do. Traditionally, "telephony" and "systems" have been considered separate. Personally I'm a sysadmin AND telephony bod with around 25/15 (respectively) years experience. My PBXs (generally Asterisk with FreePBX) have quite a few sources of intelligence about what is inbound, beyond CLID. I also look after quite a few email systems, often fronted by an Exim MTA with an attendant rspamd or spamassassin (int al).
      - wlesieutre 8y ago
        I haven't set it up, but how does it break mail lists? Do you mean like using third party providers to send emails with your own domain in the From address?
        toast0 8y ago
        It is (or was) common for mailing lists to keep the From header when forwarding mail to a list. The envelope sender is commonly changed to refer to the mailing list for bounce processing, and often a mailing list footer is added, sometimes the subject is adjusted and other administrative headers are added. Changing the subject or adding a footer will almost always break the DKIM signature, and DMARC won't like it anyway, because the From address and the envelope sender don't have the same domain (alignment). This makes it pretty hard to use DMARC for a public domain. It's not so bad to use it for a corporate domain, and it helps a bunch if your domain is being used to source phishing; except that people still think you sent it when it comes from admin@yourlocaldentist.crappyhosting.example.org which is clearly some ancient web mailer script that was compromised 20 years ago, but still remains online. (I'm totally not bitter!)
afo 8y ago
A better analogy that I use (especially with nontechnical folks) is the return address on an envelope. You can, technically, write anything in it and there’s no way to guarantee it’s authentic.
- gerdesj 8y ago
  In email the From: address rarely delivers the mail. From: and To: are the ones that you see in your mail client and correspond to the addresses on the letter within. For example here are some headers from some spam I received: From: "Jeremy Adamson" <jeremyadamson@illusion24.com> Reply-To: "Jeremy Adamson" <jeremyadamsonr@yahoo.com> From: is what I see in my client and Reply-To: is where a reply would go to. This one is much better, note how I'm BCCd and To: is complete bollocks: Reply-To: dr.ahmed.faruk@outlook.com From: Dr Faruk Ahmed <dr.faruk.ahmed1@gmail.com> Subject: MANAGER AUDIT AND ACCOUNT DEPT To: undisclosed-recipients:; BCC: <gerdesj@blueloop.net> Return-Path: dr.faruk.ahmed1@gmail.com Given that Reply-To and Return-Path are in different domains, where would a reply go to?
  - JamesBarney 8y ago
    What about an out of band verification by the carriers? Basically a large registry. When I call someone I tell t-mobile who I'm calling, and they register it. Then on the receiving end Verizon checks with T-mobile or a central registry, and says yep James's number is calling this number. Then it marks it as a verified call.
    - gerdesj 8y ago
      Bear in mind that it is not in a carrier's (financial) interest to drop a call. Carriers are not required to verify CLID either. There are lots of good things that telephony could be required to do but they are not and they wont.
    - Splines 8y ago
      iOS/Android could do something like this. You register your number with Apple/Google and link your account with them. When you call someone you set a field on your account that you're calling someone. When the person who you're dialing gets rung, their dialer can look up Apple/Google and see if that number was indeed calling them, and add a "verified" checkmark to the call. This leads down a privacy/metadata rabbit hole, but there are probably ways to make this a lot better. In any case, the phone OS can do some out-of-band signaling and just avoid dealing with the carriers altogether. Although if you're doing all that then why not just make a call using voip...
walrus01 8y ago
The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN. Which nobody wants to pay money to completely replace.
- gerdesj 8y ago
  True, but you can use your firewall for SIP'n'RTP or IAX2. Creative use of firewall rules can be really powerful. For a very simple example: block VoIP from AWS's address ranges (serious gain). A classic response for anon calls in telephony is to make the caller record a short identifying message and then play that to the potential recipient. The potential recipient then decides whether or not to accept the call - your staff (family, whatever) become the firewall. Remember that calls are billed to the caller by the terminating provider so this is OK (caller pays). Those are two simple examples of using IP and humans to firewall telephony. Just because telephony is a bit crap on the identification side does not mean that you can't deploy lots of other weaponry to keep yourself safe. If you look deeply into SIP and IAX2, you get loads more options as well.
- zrm 8y ago
  > The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN. Why not? That's how it was done for email. SPF doesn't prevent interoperability for sending domains that don't use it or recipients that don't verify it. What it does is inhibit forged messages from a domain that does use it to a recipient that does verify it. Then the more senders who have an SPF record, the stronger a spam signal it is for a domain to not have one, and the stronger the incentive gets for senders to use it. It's already in the recipient's interest to verify it when it's used. They could even use DNS for this exactly like email. Create a lookup zone equivalent to in-addr.arpa but for phone numbers.
  - walrus01 8y ago

coaxial 8y ago

Curious: how does the PBX verify caller ID? Do you know how it works in practice?

gerdesj 8y ago
It doesn't actually verify it, all it can do is read it. Just like email. When the PBX is told that the caller is say 01460223344 (I'm in the UK) then it would infer that the caller is from Crewkerne in Somerset due to the 01460 which is a designated area code. It may also be able to look up the whole number and infer a source. However, just like email the CLID can be trivially faked and just like email, the lookup in your contacts is then wrong and potentially dangerous. In the case of telephony, if you subscribe to the BT service (I presume it still exists) that will return a name given a CLID (just like DNS for a price!) then you may end up with completely the wrong thing on your display. Just to re-iterate the point: a PBX/phone/whatever cannot ... CANNOT ... verify CLID (Calling Line IDentification) it can only show what is presented to it. Remember this, please: CLID is nominally under the control of the caller and could also be changed in transit. It should absolutely NOT be considered authoritative in any way.
- wlesieutre 8y ago
  It's not quite "Just like email" because email has systems in place to authenticate this, while phone systems do not. https://en.wikipedia.org/wiki/DMARC https://en.wikipedia.org/wiki/DMARC
  - gerdesj 8y ago
    Have you ever tried to implement DMARC? DKIM and SPF are OK but DMARC breaks mail lists. Yes there are ways to mitigate but it might not be worth it unless you also do DNSSEC as well. Well actually I believe that every little helps and use every weapon available. I do think that the analogy works really well. PBXs can have quite a few weapons of their own to attempt to authenticate callers. For example you can pass "anonymous" calls to a dialplan that gets the caller to identify themselves and then play that to the recipient who then gets to allow/disallow the call - basically make the (human) recipient part of the firewall. Also, PBXs that deal with VoIP can use IP rules just like a firewall to make decisions on what to do. Traditionally, "telephony" and "systems" have been considered separate. Personally I'm a sysadmin AND telephony bod with around 25/15 (respectively) years experience. My PBXs (generally Asterisk with FreePBX) have quite a few sources of intelligence about what is inbound, beyond CLID. I also look after quite a few email systems, often fronted by an Exim MTA with an attendant rspamd or spamassassin (int al).
    - wlesieutre 8y ago
      I haven't set it up, but how does it break mail lists? Do you mean like using third party providers to send emails with your own domain in the From address?
      - toast0 8y ago
        It is (or was) common for mailing lists to keep the From header when forwarding mail to a list. The envelope sender is commonly changed to refer to the mailing list for bounce processing, and often a mailing list footer is added, sometimes the subject is adjusted and other administrative headers are added. Changing the subject or adding a footer will almost always break the DKIM signature, and DMARC won't like it anyway, because the From address and the envelope sender don't have the same domain (alignment). This makes it pretty hard to use DMARC for a public domain. It's not so bad to use it for a corporate domain, and it helps a bunch if your domain is being used to source phishing; except that people still think you sent it when it comes from admin@yourlocaldentist.crappyhosting.example.org which is clearly some ancient web mailer script that was compromised 20 years ago, but still remains online. (I'm totally not bitter!)

afo 8y ago

A better analogy that I use (especially with nontechnical folks) is the return address on an envelope. You can, technically, write anything in it and there’s no way to guarantee it’s authentic.

gerdesj 8y ago
In email the From: address rarely delivers the mail. From: and To: are the ones that you see in your mail client and correspond to the addresses on the letter within. For example here are some headers from some spam I received: From: "Jeremy Adamson" <jeremyadamson@illusion24.com> Reply-To: "Jeremy Adamson" <jeremyadamsonr@yahoo.com> From: is what I see in my client and Reply-To: is where a reply would go to. This one is much better, note how I'm BCCd and To: is complete bollocks: Reply-To: dr.ahmed.faruk@outlook.com From: Dr Faruk Ahmed <dr.faruk.ahmed1@gmail.com> Subject: MANAGER AUDIT AND ACCOUNT DEPT To: undisclosed-recipients:; BCC: <gerdesj@blueloop.net> Return-Path: dr.faruk.ahmed1@gmail.com Given that Reply-To and Return-Path are in different domains, where would a reply go to?
- JamesBarney 8y ago
  What about an out of band verification by the carriers? Basically a large registry. When I call someone I tell t-mobile who I'm calling, and they register it. Then on the receiving end Verizon checks with T-mobile or a central registry, and says yep James's number is calling this number. Then it marks it as a verified call.
  - gerdesj 8y ago
    Bear in mind that it is not in a carrier's (financial) interest to drop a call. Carriers are not required to verify CLID either. There are lots of good things that telephony could be required to do but they are not and they wont.
  - Splines 8y ago
    iOS/Android could do something like this. You register your number with Apple/Google and link your account with them. When you call someone you set a field on your account that you're calling someone. When the person who you're dialing gets rung, their dialer can look up Apple/Google and see if that number was indeed calling them, and add a "verified" checkmark to the call. This leads down a privacy/metadata rabbit hole, but there are probably ways to make this a lot better. In any case, the phone OS can do some out-of-band signaling and just avoid dealing with the carriers altogether. Although if you're doing all that then why not just make a call using voip...

walrus01 8y ago

The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN. Which nobody wants to pay money to completely replace.

gerdesj 8y ago
True, but you can use your firewall for SIP'n'RTP or IAX2. Creative use of firewall rules can be really powerful. For a very simple example: block VoIP from AWS's address ranges (serious gain). A classic response for anon calls in telephony is to make the caller record a short identifying message and then play that to the potential recipient. The potential recipient then decides whether or not to accept the call - your staff (family, whatever) become the firewall. Remember that calls are billed to the caller by the terminating provider so this is OK (caller pays). Those are two simple examples of using IP and humans to firewall telephony. Just because telephony is a bit crap on the identification side does not mean that you can't deploy lots of other weaponry to keep yourself safe. If you look deeply into SIP and IAX2, you get loads more options as well.
zrm 8y ago
> The problem with SS7 is that you extend your SMTP analogy, there is no way to implement the equivalent of SPF, DKIM and DMARC for verification of incoming traffic without breaking SS7-to-SS7 links between the vast majority of installed phone switching gear out there on the PSTN. Why not? That's how it was done for email. SPF doesn't prevent interoperability for sending domains that don't use it or recipients that don't verify it. What it does is inhibit forged messages from a domain that does use it to a recipient that does verify it. Then the more senders who have an SPF record, the stronger a spam signal it is for a domain to not have one, and the stronger the incentive gets for senders to use it. It's already in the recipient's interest to verify it when it's used. They could even use DNS for this exactly like email. Create a lookup zone equivalent to in-addr.arpa but for phone numbers.
- walrus01 8y ago