[AusNOG] Rise in fake calling numbers?

Tue May 1 09:12:38 EST 2018

There is work going on in the IETF ART WG with RFC7340 and RFC 8224 leading
the way.

I'm not convinced we will get widespread implementation.

Looks like caller ID spoofing is likely to persist for a while...

Narelle

On Tue, 1 May 2018, 8:24 AM Nick Stallman <nick at agentpoint.com> wrote:

> My 2c, it is really trivial to get a voip service with zero caller ID
> validation.
>
> I've got one, and while we have a legitimate purpose for it, it only took
> a single email to request validation to be turned off and it didn't even
> cost anything.
> Works perfectly with all telcos in Australia, I've never had an issue with
> our spoofed caller ids (typically our client's real numbers) not working.
>
> Personally I don't think strictly validating caller id numbers is a great
> solution.
> It would have been way better if phone calls recorded a trace of their
> path like email does.
> I can send an email from bill.gates at microsoft.com but the email headers
> clearly show the real origin and allow complaints to be handled properly.
>
> It's not going to happen (certainly not all the way to consumer's phones),
> but it would be an extremely effective solution.
>
> On 01/05/18 07:19, Matthew Moyle-Croft wrote:
>
>
>
> On 30 Apr 2018, at 2:03 pm, Narelle <narellec at gmail.com> wrote:
>
>
> The problem is that they are now using genuine third party numbers.
>
> And the poor ducks that actually own them end up receiving a million calls
> in response.
>
> Please everyone - make sure you secure your call servers and ensure good
> authentication!! Not to mention enforcement of number ownership in your
> configs…
>
>
> This happens because people aren’t validating CLID on interconnects. It’s
> not really about security and authentication of VOIP infrastructure. It
> came about because people want to set CLID on outbound calls via carriers
> that don’t own their numbers. In some ways it’s consumer/business friendly
> BUT abuse leads to phone calls being a trashfire. In the US it’s meaning
> that some carriers run all calls through some validation and present some
> info about whether it’s real or not or the likely actual origin. T-Mobile
> are doing this - super helpful as you get info on whether it’s a scam or
> not. HIGHLY recommend Australian carriers get onto this. It’s cut down the
> amount of dodgy calls in the US a lot recently.
>
> MMC
>
>
>
> Narelle
>
>
>
> On Tue, 1 May 2018, 1:23 AM Chris Watts <Chris.Watts at techanalysis.com.au>
> wrote:
>
>> Yea got 2 today and one yesterday all were the Telstra scam, you know the
>> one... alleging to be from Telstra technical support.
>> 0403 567 139
>> 0161 926 190 91
>> +91 80-432 640 00
>>
>> I block them at the pbx so they cant call me from that number again.
>>
>> Chris.
>>
>>
>> On 1/05/2018 1:05 am, Tom Storey wrote:
>>
>> Im based in London, but a colleague of mine has been getting a few calls
>> on his mobile recently from random Australian numbers.
>>
>> Random-ish anyway. The last 3 digits seem to be the same, although that
>> could be entirely coincidental.
>>
>> 0403 595 417
>> 0401 499 417
>>
>> Does anyone else see the same kind of thing, or am I reading way too far
>> in to it?
>>
>>
>> On 23 April 2018 at 07:18, Narelle <narellec at gmail.com> wrote:
>>
>>>
>>> And here is the promised summary of responses! Thanks team. Please send
>>> any additional commentary to narelle.clark "at" accan.org.au
>>> -nospamplease
>>>
>>> Problem statement:
>>> Consumer reps are hearing a rise in the incidence of VoIP calls faking
>>> their caller ID for the purposes of spamming and scamming.
>>>
>>> Consumers check the caller ID on their handset CND and accept the
>>> Australian sourced number, only to find it is a complete scam. This is
>>> often tied to the 'missed call scam' but now they are presenting using
>>> genuine Aussie phone numbers and the actual owners aren't happy.
>>>
>>> Summary of responses:
>>> This could be from a few likely possibilities 1. a local VoIP system has
>>> poor security and has been compromised and is being used as a local
>>> dialler. 2 incorrect configuration of a VoIP server with incorrect numbers
>>> on outbound calls within Australia or 3 outright fraud from overseas VoIP
>>> servers presenting as Australian numbers.
>>>
>>> Ideally, this could be handled similarly to IP address matching within
>>> BGP ASes, but not likely to be as simple.
>>>
>>> By inference any provider doing so would be in contravention of the ACMA
>>> Numbering Plan 2015 Part 2 s102 and therefore fines are payable:
>>> "s 102 Carriage service provider must not issue a number that it has not
>>> been
>>> allocated
>>> A carriage service provider must not issue a number to a customer unless
>>> the
>>> carriage service provider holds the number."
>>>
>>>
>>>
>>> De-identified responses (some typos corrected):
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<---------
>>> I'd say that in my experience, most of the time it's not spoofed CID or
>>> ANI, rather a compromised set of SIP gateway credentials. Once in, they
>>> either don't bother setting CLIP (because it's a scam call) or they set it
>>> to something that the caller is likely to pick up - local area code prefix
>>> or similar. The side effect of this is the usual network security approach,
>>> rather than telephony security - setting up fail2ban, choosing strong
>>> passwords, whitelisting source IP's that you know are cool, blacklisting
>>> certain countries IP ranges (India...) yada yada.
>>>
>>> Personally, for our call-center kids, we use zendesk for telephony,
>>> single-sign-on via gsuite authentication, which in turn is protected by
>>> password policies and enforced 2factor auth. Works well.
>>>
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<---------
>>>
>>> Most network operators will filter the source CallerID to ensure that
>>> only CallerIDs attached to the calling account are able to make a call.
>>>
>>> The ACMA is rather strict in regards to this and network operators can
>>> face fines if they knowingly allow a 'spoofed' callerID without verifying
>>> the number owner.
>>>
>>> Most larger network operators/carriers have implemented filtering across
>>> their network so if a report of nuisance calls is received they have
>>> procedures
>>>
>>> in place to deal with it quickly.
>>>
>>>
>>> I would suspect that the calls you are seeing may come from a
>>> compromised device or account with the most unlikely being an untrustworthy
>>> operator.
>>> Technically speaking the best you can do is report every case to your
>>> provider and police then block the number if it's not a legitimate number.
>>>
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<---------
>>>
>>>   I would say they are likely coming in from overseas based telco's.
>>> All of the Australian based operators that I'm aware of take their
>>> responsibility seriously when setting the outbound calling number that
>>> calling customer has the right to use that number. We will not set an
>>> outbound CLID for our customers unless the inbound is churned to us or the
>>> customer has provided proof they own the rights to the number. Like their
>>> mobile number for example.
>>>
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<---------
>>> Yes I have seen this. Even personally had it
>>> Had the solar grant scam call with its Caller ID as a Gladstone number.
>>>
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<
>>> Unfortunately this is very hard to protect against. Pretty much relying
>>> on the source carrier to so their due diligence and actually stop you from
>>> setting a number owned by someone else as your caller ID.
>>>
>>> Unfortunately there are a lot of VoIP providers that don't do this.
>>> There are even some VoIP systems that are open to the internet that allow
>>> unauthenticated or default user/pass to connect..
>>>
>>>  --------8<  --------8<  --------8<  --------8<  --------8<  --------8<
>>>  --------8<  --------8<
>>>
>>> I often (as in sometimes several times a day) receive scam calls from
>>> the 'I'm from Telstra, I regret to inform you we will be cutting off your
>>> internet' or 'you have a virus I'm calling to help you'  variety, some of
>>> them lately showing a obviously dodgy caller ID of 61234567890.
>>>
>>> Verifying caller ID from direct customers is within their range is OK,
>>> but  could a large international gateway verify:
>>> (a) all caller IDs coming up from customer VoIP networks aggregating
>>> throusaands of number ranges from downstream and downstream-of-downstream
>>> customer VoIP gateways?
>>>     - possibly doable, in the same way ISPs require downstream ISPs to
>>> register IP address block ranges to get them into a filter before they'll
>>> allow the ranges into BGP routing rables
>>>
>>> (b) incoming calls from upstream wholesale suppliers, including
>>> international networks, which may or may not have any CLI information at
>>> all? In telephone networks looped calls are OK, so it is perfectly ok to
>>> recieve a call routing from an international gateway with a Caller ID
>>> starting with '+61' or any other country prefix, and to forward it through.
>>>
>>>
>>> Best regards and thanks again for the input
>>>
>>>
>>> Narelle Clark
>>>
>>>
>>> On Mon, Apr 23, 2018 at 1:22 PM, Narelle <narellec at gmail.com> wrote:
>>>
>>>>
>>>> Hi folks
>>>> we may be hearing a rise in the incidence of VoIP calls faking their
>>>> caller ID for the purposes of spamming and scamming.
>>>>
>>>> Consumers check the caller ID on their hand CND and accept the
>>>> Australian sourced number, only to find it is a complete scam. This is
>>>> often tied to the 'missed call scam' but now they are using genuine Aussie
>>>> phone numbers and the genuine owners aren't happy.
>>>>
>>>> From my rusty experience at setting up VoIP systems, you should be able
>>>> to impose filters on incoming calls  at the network level here the number
>>>> doesn't match the source - can people please give me a clearer update on
>>>> this from the trenches?
>>>>
>>>> What are the good housekeeping steps for network operators?
>>>>
>>>> Off list please and I'll summarise the responses,
>>>>
>>>> thanks in advance
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Narelle Clark
>>>> narellec at gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Narelle
>>> narellec at gmail.com
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>
>>
>> _______________________________________________
>> AusNOG mailing listAusNOG at lists.ausnog.nethttp://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
>
> _______________________________________________
> AusNOG mailing listAusNOG at lists.ausnog.nethttp://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> --
> Nick Stallman
> Technical Director
> [image: Email] nick at agentpoint.com
> [image: Phone] 02 8039 6820 <0280396820>
> [image: Website] www.agentpoint.com.au
> [image: Agentpoint] <https://www.agentpoint.com.au/>
> [image: Netpoint] <https://netpoint.group/>
> Level 3, 100 Harris Street, Pyrmont NSW
> <https://maps.google.com/?q=Level+3,%0D%0A++++++++++++++++++++++100+Harris+Street,+Pyrmont+NSW&entry=gmail&source=g>
> 2009 [image: Facebook] <https://www.facebook.com/agentpoint/> [image:
> Twitter] <https://twitter.com/agentpoint> [image: Instagram]
> <https://www.instagram.com/Agentpoint/> [image: Linkedin]
> <https://www.linkedin.com/company/agentpoint-pty-ltd>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20180430/15d4dbe4/attachment.html>