Unbelievable hacks: Money Transferring with Caller Id Spoofing

Everyone in the security industry easily remembers Kevin Mitnick during his Art of Deception tour, where he showed how to call somebody else displaying a fake incoming phone-number on the receiver’s phone. In that case the phone number of the president of the United States. This is "Caller Id Spoofing" (Kevin Mitnick at CNBC).

Presented by Kevin as a strong weapon in Social Engineering attacks, we discuss it here as a way to bypass authentication checks during money transfer. People usually laugh of nice tricks, but not when the subject is their money.

Phone Call authentication is an emerging way of authenticating money transfers or other types of disposal operations. This particular authentication method has the great advantage of posing zero costs for the organization and for the individuals. In fact as soon as the call is received by the bank, the call is dropped without charging the calling card.

When a customer call the dynamic phone number for authentication too often the only information that is checked is the Caller Id. The standard incoming caller identifier is the information that is displayed on the mobile phone of the phone call receiver.

This set of information can be dangerously used to identify the user that is authenticating a particular transaction. I say dangerously, because the caller id is very prone to tampering as showed several years ago in the workshop “Phreaking in the age of Voice Over Ip”:

Before we start the questions we need to answer are:

1) Is caller ID Spoofing still alive?
2) Does it work in our country? (ex. Italy for us)
3) Is it enough for performing an Identity Spoofing attempt and to breaking authorization security?

Is caller ID Spoofing still alive? To answer the first question, we can say that phone operators are very based on legacy systems. SS7 standard is still adopted and valid, as the calling rules are pretty much the same that were in use at the time that “Lucky 225” was presenting. So yes, Caller Id spoofing is still a valid attack.

Does it work in our country? Unbelievably Yes. Phone operators use to blacklist malicious operators that were known to perform Caller Id Spoofing attacks. This means that it’s possible for an attacker to find a valid voip provider that is not blacklisted to put into place a successful Caller Id Spoofing attack.

Is it enough for breaking authorization security? It Depends. The bank should badly rely only on Caller Id verification which is not a best practice. Caller Id as demonstrated below can be arbitrarily modified, so more information should be requested to correctly identify the customer.

How many banks rely only on Caller ID for the security of their Phone Back authentication system? We do not have precise statistics for Europe, but we tested it against 2 banks and both were vulnerable to this attack.

How the attack works

Imagine that at the time of authorizing your wire transfer your online bank will print the following information on your screen:

At this time if the attacker knows the phone number associated to the customer bank account can place a phone call with a spoofed caller id.

Voip Services offer the possibility to setup your Asterisk voip central and to route call defining your custom caller id.

Normally an attacker should:

1) Have his own virtual server, possibly in the country where the VOIP service is rented
2) Rent a VOIP service that permits to specify an arbitrary caller ID which is not blacklisted by your country Phone operator

However Google helps in finding ready setups as a “pay per go” service.

The following is an example of the service which permits to spoof phone Cal Ids also in Europe and Italy.

To be honest, this search took some time, because a very limited number of “Phone Spoofing” services permit to place phone calls across Europe. Whereas in the United States Caller Id spoofing is somehow tolerated, in Europe is completely illegal.

This service can also be made totally anonymous using Skype and calling directly the Service Phone Number:

A Female voice will ask to enter your user ID, the Number to Call and The Fake User ID


Conclusion

Phone Back authentication systems should be tested against Caller Id Spoofing, because this attack is going to be easier and easier in the future. Caller Id authentication is not secure, other information should be used for securing the transaction, unless a secure handshake is put into place.

Ye Olde Crockford JSON regexp is Bypassable

Introduction

While doing some test with DOMinator I found several sites and applications using the following JSON parse routine:

function jsonParse(string, secure) {
if (secure &&
!/^[,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]*$/.test(string.replace(/\\./g, "@").replace(/"[^"\\\n\r]*"/g, ""))) {
return null;
}
return eval("(" + string + ")");
}

or similar.
It turned out that eval function can be reached on IE and execute arbitrary javascript code.
Suppose, in fact, that the JSON String comes from a source like location.hash and consider the following code:

jsonParse(location.hash.slice(1),true);

So far, it was considered safe and, in fact, several javascript libraries use it.

Regexp Analysis

By looking at the regexp, it can be noted that the following string is considered valid:

jsonParse('a')

because of the Eaeflnr-u part with no quotes.

This means that even if the string does not represent a JSON Object it'll be eval'ed.

Once found this behavior, it's important to find window objects that match the regexp.
I did it by executing the following code:

for(var aa in window)
if( aa.match(/^[,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]*$/))
console.log(""+aa)

Which resulted in the following window objects:

• self
• status

Hence is possible to reference self["anyobject"]["anyotherobject"] in the eval.

Exploiting JSON Bypass

What's been described so far, shows that, depending on how that result is used, it will be potentially possible to change the flow of inner javascript.

There is more fun if the victim uses Internet Explorer.
According to the wonderful Sirdarckcat and ThornMaker research on Internet Explorer is possible to execute arbitrary JavaScript using the following code:

+{ valueOf: location,
toString: [].join,
0: 'payload',
length: 1
}

So, considering that self object can be used, the following string will be treated as a valid JSON payload:

+{ "valueOf": self["location"],
"toString": []["join"],
0: "javascript:alert(1)",
length: 1
}

This payload bypasses the old Crockford's regexp and will lead to arbitrary JavaScript execution.

Countermeasures and fix

The new json.js uses a brand new regexp which "should" be safe, however it's always better to use json_parse.js which doesn't use eval.

Finally, consider that, even if the JSON parser will work as expected, the attributes and values are not validated so don't trust them!

P.S.
This post doesn't mean that Firefox or other browsers are not exploitable. It's just a matter of time to find some working vector. So if you find it and want to share, leave a comment!