Caffeinated-Geek.com

Decided to screw around with my AT&T voicemail service today; our local GSM carrier, Edge Wireless, was recently acquired by AT&T, and the time came to swap SIM cards and set up voicemail on the new system.

Noticed a voicemail option (enabled by default) allowing you to skip password entry if calling from your mobile — of course, my interest was in breaking into voicemail boxes with this option enabled. You see, I manage telephone systems with PRI (ISDN Primary Rate Interface) connections, and can very easily spoof my Calling Party Number (Caller ID).

I’ve heard of this issue before, and I’ve toyed around with doing this with other telephone services that “authenticate” based on CID before, too. I just cannot believe that this security vulnerability STILL exists – it’s been widely known for over 2 years!

Fudging caller ID is extremely easy. Most carriers will let PRI customers do it (we use it for forwarding calls with the original caller ID info intact, and for calling from our call center numbers). Many VOIP companies let their customers do it (for the same reasons). There are even services that take advantage of this and will allow you to visit a web site and enter a CID to call from, number to call to, and your telephone number – then bridge the call for you.

With regards to AT&T’s voicemail system, I can simply set my Caller ID to that of my victim and call the number, and hope it rolls to voicemail, but getting a call from yourself might arouse suspicion. Even better, I can just call the voicemail service center number. This is the number that the provider call-forwards busy/no answer/unavailable calls to, and can be viewed from most phones, and you can reach it from the PSTN (our local area’s service center number is 5037030985).

The iPhone uses a completely different voicemail system (to support the visual voicemail), and the service center number for regular VM users doesn’t seem to support login for iPhone users. However, I’ve tested with a couple of iPhone users here, and calling the user’s phone directly and going to voicemail still allows this vulnerability to be exploited.

I had hoped that this feature had at least used ANI for identification purposes, but sometimes ANI’s not much better; one of my carriers have a misconfigured switch which sends whatever I stuff as the Caller ID field as my ANI — I’ve even told them about it, but they don’t seem to care. After all, it could be handy for “calling from a home phone” to toll-free credit card activation services, making harassing telephone calls to toll-free operators, or screwing with your E-911 operator. Yes, we arranged a test call with 911, and the calltaker saw the address of the telephone number I forged.

The short story? Enable your voicemail password if you haven’t already. Call your mailbox, and if it doesn’t ask for your password, select Personal Options, Administrative Options, Password, and Turn Password On. Do it now, it only takes a minute. Go on, do it.

Seriously, I’ll wait.

You done?

Good.

Now, if you desire, call AT&T and complain. I’ve done it already, as have many other people, and it hasn’t helped — yet. But the more people who make them aware of this glaring security vulnerability that is a DEFAULT SETTING, the better.

Security telco

Why do people completely filter ICMP echo?  I have no problem with folks re-prioritizing or rate-limiting it, but outright filtering a VERY useful diagnostic tool for network guys like myself is really annoying.

Anyway, if you do decide to filter ICMP echo packets, please be sure you don’t send an ICMP unreachable from the device that’s filtered:

kgasso@wibbly:~$ ping -c 1 66.131.100.81
PING 66.131.100.81 (66.131.100.81) 56(84) bytes of data.

From 66.131.100.81 icmp_seq=1 Packet filtered

--- 66.131.100.81 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

So, the host I pinged – to test reachability – sent me a response saying that I’m not allowed to do that, confirming what I wanted to know in the first place, that the host was reachable. Uh, yeah… You kinda blew your cover there, buddy.

On second thought, I like this strategy.  I’m going to start answering my doorbell by audibly saying “nobody’s home”.

Complaints, Network Admin, Security firewall

We received a letter today regarding Alta Resources, Inc – a credit card processor who handles services for the Disney Movie Club regarding a security breach of our credit card information:

Dear Disney Movie Club Member,

We have been informed of an incident at Alta Resources, Inc., a company that processes and fulfills orders for the Disney Movie Club. This incident involved credit card information received by Alta Resources from a number of Disney Movie Club members.

*snip*

One of Alta Resources’ employees sold certain credit card information to federal law enforcement agents, as part of an undercover sting operation, in May 2007. This information included your name, address, credit card number and expiration date, and credit card type (e.g., Visa, Mastercard, American Express, or Discover), and may have included your telephone number and email address if you had provided that contact information to us. We have been assured that the card security code (e.g., the CVV or CVC code) for your credit card was not included in this information.

*snip*

The individual involved in this incident is now longer employed by Alta Resources and no longer has access rights to Alta Resources’ premises or computer systems. You also should know that Alta Resources now has taken additional corrective and precautionary measures, and has been independently certified under the Payment Card Industry Data Security Standard, and industry standard for safeguarding of consumer credit card information.

At least they’re letting their customers know. Glad they weren’t being total dimwits and storing CVV codes in a database. Also glad that the genius trying to do this had his first “successful” sale to a government agent.

So, I’m curious – does the last paragraph I posted from the letter mean they weren’t following PCI standards (were not PCI compliant) before?

Full scan of the letter:

Security crack, credit card