It is essential to keep in mind that the use of a Mobile Wallet encompasses an entire payment infrastructure, to which it is prone to many other Security issues and vulnerabilities. Our last article started to examine these major components, as well as the threats that are posed to them.
In this article, we complete reviewing the last two components of the Mobile Wallet Infrastructure (as well as their associated Security vulnerabilities), as well as the examining the Security weaknesses of the most widely used Mobile Wallet- the Apple Pay.
The Security Threats Posed to the Mobile Wallet Infrastructure-Continued
The remaining subcomponents of the Mobile Wallet Infrastructure include the credit card issuer and the Mobile Payment Applications Providers.
From the perspective of the credit card issuer:
This is the entity that issues and distributes the credit card to the end user. From this angle, there are numerous Security breaches which can occur, which are as follows:
àThe compromise or eventual failure of the Payment Authorization Process:
In fact, this is one of the oldest types of threats that credit card issuers have always been on the lookout for. For instance, Cyber attackers have always tried to compromise the Central Servers in which the Fraud Controls have been put into place. One new trend that is emerging from this is the Cyber attacker now attempting to raise the credit or spending limits on the credit cards which have been authorized for Mobile Wallet based transactions.
àThe capture of actual credit card holder information and data:
Just like the threat last described, this vulnerability has also been around for a long time. As the name of it implies, the primary goal here is to capture the confidential information of the credit card holder. This not only includes the actual credit card number itself, but also the Social Security number of the cardholder. This can be accomplished either covert Social Engineering tactics, and the use of what is known as “Advanced Persistent Threats,” or also known as “APTs” for short. If this method is used, it is the Encryption Keys which are primarily targeted, to decrypt the sensitive information and data which resides on the Central Servers of the issuer.
àPayment Fraud: This occurs when a Cyber attacker is in actual possession of the Mobile Wallet information of the end user and uses it to make an unauthorized transaction, in a manner very similar to that of actual credit card fraud. Although this has become more difficult to accomplish with the use of token technology (which was also described in detail in the first Mobile Wallet article), this is still a prevalent risk, as the sophistication of the Cyber attacker keeps increasing.
From the perspective of the Mobile Applications Payment Providers:
This is the entity that creates the mobile app for the Mobile Wallet. As mentioned, this is what gets downloaded onto the Smartphone of the end user, and from there, the credit number is entered. After that, the process is then initiated to confirm the identity of the end user. From this perspective, there are a number of Security threats and vulnerabilities as well, which include:
àThe compromising of the user profile:
This type of attack can typically occur during the verification process as just described. For example, a Cyber attacker can enroll a stolen credit card into either Google Wallet or Apple Pay, and from there, maliciously gain access to the user profile of the actual credit card holder, and from there, manipulate any of the confidential information of the end user.
àA direct hit on the token creation services:
As it was described previously, this is usually outsourced to an independent third party. However, a Mobile Applications Payment Provider can also implement this service into their own infrastructure if they wish too. However, where ever it is done, the token creation services are a massive target for the sophisticated Cyber attacker. The primary reason for this is that it is here where the Cyber attacker manipulates the processes which encrypt and decrypt the tokens, as well as its integrity and availability.
àThe traditional DDoS attacks:
It has often thought that the Cyber attacker just hits on servers to incapacitate them. However, DDoS attacks can happen just about anywhere now, even the Mobile Wallet Infrastructure. In this regard, the primary objective is to hit the servers of the Mobile Applications Payment Provider so that all Mobile Wallet payments become disrupted, and as a result, they cannot be processed.
The Security Issues of Apple Pay
The use of stolen credit cards:
As the last article explained in detail how an end user could enroll into the Apple Pay system, there was one big assumption that was being made: The end user is using their own authorized and verified card, not a stolen credit card. Given the sophistication of the Internet, it is easy to steal credit card numbers, especially if the Cyber attacker knows there a way around what is the known as the “Dark Web.” It has been claimed that stolen credit card numbers can be sold here for as high $2.00 apiece. Thus, the problem becomes entering a stolen credit card number into an iPhone which is provisioned with a hijacked cell phone number as well. This has been deemed to be even a form of Identity Theft, which has been labeled specifically as “Provisioning.” There is no doubt that it is easy for a Cyber attacker to enter a stolen credit card number. Although the Apple Pay does confirm the identity of the end user as he or she logs into the iPhone, it does not confirm the identity of the end user as they enter in a credit card number. In other words, although the end user is the legitimate owner of the iPhone, they could also be the “owner” of a stolen credit card number without any questions being asked as they enter it into the Apple Pay. The primary reason for this is that Apple does not confirm the validity of the credit card number (although it does make use of Encryption and tokens) after it has been processed by Apple Pay; instead, they leave that to the issuing banks to accomplish this task. Although these banks do have specialized Fraud Prevention Protocols in place (which just essentially check for any anomalies), the truth of the matter is that the algorithms which formulate the basis of these protocols need to be revamped entirely and fine-tuned to keep with the ever-increasing sophistication of the Cyber attacker. However, the vital question to be asked, is just exactly where in the process of confirming the credit card number in Apple Pay is this fraudulent activity set into motion? It occurs at the point where the issuing bank receives the credit card information as well as the information which is relevant to the iTunes account; the general location of the end user, and any relevant links to the mobile banking apps which are installed on that iPhone device. Thus, given the outdated Security features that the issuing banks possess, all the Cyber attacker must do is hijack this information which is transmitted from Apple Pay to the issuing bank. Then from there, he or she needs to obtain a new iPhone device, load in the stolen credit card information, and covertly steal the phone number of the person to whom the stolen credit card belongs to.
The Wi-Fi Hotspot:
There is no doubt that there are serious Security related issues when it comes to using a Wi-Fi hotspot which is offered by a public venue. For instance, although many of them require a username and password combination, there is no guarantee that the actual network based connection is encrypted. Most often they are not, and as a result, just about any kind of malicious, covert activity can take place against the end user, without them even knowing about it. To make matters even worse, there is even the issue of a fake Wi-Fi hotspot being set up by Cyber attackers, making them look legitimate to the end user, such as ones from Xfinity, AT&T, Verizon, etc. This issue of the fraudulent hotspot has now started to lend itself to affecting Apple Pay as well. For instance, researchers at the Cybersecurity firm known as Wandera have discovered a serious vulnerability in the iOS Operating System which basically allows for a fake Apple Pay page to appear on the iPhone if it is connected to a fraudulent hotspot. The end user is then prompted to enter in their credit card information, which will then, of course, be captured by the Cyber attacker to conduct fraudulent Mobile Wallet based transactions. It is important to note that this spoofed Apple Pay page has its flaws, meaning, to a trained eye, one can tell that it is a fake. However, to the end average end user, the probability is high that they will not be able to distinguish if it is a fake page or the real thing. This is the assumption that Cyber attackers are banking on as they launch these fraudulent Apple Pay pages. In technical terms, this type of attack is known precisely as a “Captive Portal” attack. This occurs when an iPhone device tries to connect to any Wi-Fi hotspot (including the false ones) with a known Service Set Identifier (also known as an “SSID”). They are also broadcasted out to the public Internet domain even when they are not connected to a specific network, via the use of various “Probe Messages.” From this point, a fake Wi-Fi hotspot could then initiate what is known as a “Probe Request” to connect to a legitimate network by disguising itself as a legitimate hotspot. From here, once this connection has been established a Cyber attacker can then deploy a fake Apple Pay page onto any iPhone device. For that matter, it does not have to an Apple Pay page; the Cyber attacker can deploy just about any spoofed-up page they wish, to capture the credit card information, or any other confidential data (such as the username and password combination). The “Captive Portal” attack can occur when an end user is just about to complete an Apple Pay transaction. A Cyber attacker could be nearby, deploying the spoofed Apple Pay page. The end user will then, of course, be prompted to enter in their credit card information, thinking that it is a regular part of the process to have to re-enter their credit card number again, even after they have entered it in the first time in the set-up process. However, the truth of the reality is that the Cyber attacker is covertly capturing the credit card information for their own gain.
Ethical Hacking Training – Resources (InfoSec)
In the illustration above, the legitimate Apple Pay page is on the left, and the spoofed Apple Pay page is on the right.
In summary, our last three articles on Mobile Wallets have examined the technical details which comprise it, as well as the Security risks which are posed to it. In this regard, it is important to keep in mind that the use of the Mobile Wallet just does not involve merely using the mobile app and tapping your iPhone/Samsung/Windows mobile device at the Point of Sale Terminal.
Instead, it entails an entire Mobile Wallet Infrastructure, ranging all the way from the credit issuer to either Apple or Google that has created the actual app.
Because of this, there are more intermediary parties involved to ensure that a smooth Mobile Wallet can take place. However, because of these extra components, the Security risks become much more significant to this kind of Infrastructure, which were also examined in detail.
In this regard, the two most widely used Mobile Apps are those of Google Wallet and Apple Pay. The former has been around for a much longer time, and the latter just made its appearance in October 2014. It should be noted that Google Wallet has had more Security related issues than that of the Apple Pay.
The primary reason for this is that Apple has made its iOS Operating System much more proprietary in nature; and, it makes use of Cryptographic tokens which serve as a proxy for the actual credit card number.
However, given the sophistication level of the Cyber attacker of today, the Apple Pay is also starting to suffer from severe Security vulnerabilities as well, which were also covered in this article. Perhaps one of the best ways moving forward to mitigate these risks is to make use of the various Penetration Testing tools which are available – this will be the focal point of the next article.