Recent Articles

You’ve likely heard about [Coin][1] (that’s an affiliate link), a new credit card / iPhone pairing that seeks to eliminate you having to carry multiple cards. It even has its own Sandwich video. The product itself looks fantastic, and easy to use too.

And, as surprising as this might be, I pre-ordered one.

If you read this site you are likely to be surprised by that statement because I am a pretty privacy conscious guy. Before I talk about my thoughts on the security of this system, I want to share some non-security — more practical — concerns that I have with this card.

## You Can Change Cards Easily

The first thing I thought when I watched the video was: that’s way to easy to change cards. The Coin shows that, with a push of a button, you can toggle between cards. This is great for the *user* when they are the one in possession of the Coin, but what about when you hand the card to someone else? Sure if you don’t lose sight of the card you can be sure they haven’t changed your card, but what about at a restaurant?

I’m not even assuming anything malicious — just heavy handed use of the Coin seems like it could cycle between cards and potentially net you with a personal charge on a business card.

I really hope this concern is unfounded, and that there is a mechanism in place to prevent accidental changing of your card, but I remain skeptical.

This is all that is said about this concern on the FAQ:

> We’ve designed the button to toggle cards in a way that makes it difficult to trigger a “press” unintentionally. Dropping a Coin, holding a Coin, sitting on a Coin, or putting the Coin in a check presenter at a restaurant will not inadvertently toggle the card that is selected.

That doesn’t instill confidence of any kind in me.

## What’s That?

That’s the question I expect to get when I try to use the card. Maybe you won’t get that in San Francisco, but I know I will get asked that. No matter what I say, I suspect that the cashier will assume something shady is going on.

I can imagine a couple conversations that might prevent me from using the card:

1. “Sir, you can’t use this because we only accept American Express, Visa, and Mastercard. This is neither.” “No, it *is* an AMEX, trust me.” “Sir, this doesn’t look like any AMEX I have seen. Where’s the logo?” “Ugh.”
2. “Ummm, I need the three numbers from the back of the card.” “Sure they are right here (points).” “No, I need the ones on the **back** of the card, there is nothing on the back of *this* card.” “Ugh.”

I think *people* are likely to be the biggest usability obstacles.

## Security

The Coin FAQ has an entire section on security, but it’s not all that reassuring. There are some features of the Coin that makes it a lot better than a normal card:

– Push notification if you leave the Coin behind.
– Card disables if it is out of contact from your phone for too long.

There are two primary security concerns that I see with this product:

1. That you have to give a lot of credit card info to Coin and it is then stored (from the sound of it) on *thier* servers. Now, they will be in compliance with required security standards, but how can we trust them? I don’t know, but I don’t see this aspect as any more risky than storing, or using, a credit card with any *other* company on the web. Be that Amazon, or *this* site. ((For the record I can’t see your full card number — not even if I tried. I verified that with my own account before launching the paywall.))

This is why I don’t see Coin being a big issue — it just doesn’t strike me as any bigger security risk than using your card anywhere else. In addition to that, credit card companies are actually very *good* at fraud prevention and removing fraudulent charges. I wouldn’t link a debit card to the Coin — and I don’t ever use a debit card as I don’t want people to have that direct of access to my cash — but I don’t see any reason to *not* use a credit card with it.

2. I think the next major concern is not with the security of *you* using a Coin, but with others having access to this technology. In other words, Coin sounds like a credit card skimmers dream tool. I have no doubt this presents a security risk, but why should that stop *you* from using the Coin, or any other new technology for that matter. All new technology has inherent security risks that are only figured out through wide usage.

Already waiters have been known to skim credit cards — and the rule of thumb is to not let your card out of your site — but uhh… really?

Coin, for their part, says specifically on this topic:

> The Coin app requires that you take a picture of the front and back of the card, type in card details, and then swipe the card (using a reader we provide) to ensure the card’s encoded magnetic stripe data matches the card details provided. It is not possible to complete these steps unless you are in physical possession of a card. As an additional safeguard, the Coin app will only allow you to add cards you own.

Everything but that last line is moot. My assumption is that I am out to dinner and hand my card over for payment — now the skimmer has physical possession of my card. If that’s the case, what the hell does the last line of that answer mean? How do they verify ownership? Zip codes?

My best guess is that if your card is already registered with a Coin account, it then cannot be registered with *another* Coin account. And if that is the case you are probably *more* secure owning a Coin then you would be if you didn’t own a Coin.

That’s the main flaws I see with the card. The benefit, though, seems to outweigh the risks associated with using the Coin.

If I could truly just carry around a Coin and my ID — well that would be fantastic.

[1]: https://onlycoin.com/?referral=h23SNfFb

[Marisa Taylor][1]:

> Federal officials gathered the information from the customer records of two men who were under criminal investigation for purportedly teaching people how to pass lie detector tests. The officials then distributed a list of 4,904 people – along with many of their Social Security numbers, addresses and professions – to nearly 30 federal agencies, including the Internal Revenue Service, the CIA, the National Security Agency and the Food and Drug Administration.
> Although the polygraph-beating techniques are unproven, authorities hoped to find government employees or applicants who might have tried to use them to lie during the tests required for security clearances. Officials with multiple agencies confirmed that they’d checked the names in their databases and planned to retain the list in case any of those named take polygraphs for federal jobs or criminal investigations.

And:

> “It’s very alarming and McCarthy-esque in its zeal. To put a person on a secret list because they bought the ‘wrong book’ or are associated with someone who did is overly paranoid.”

Do you *still* think that all of this is ok because you “have nothing to hide”? Do you know what books you have bought over the last decade? What software? What YouTube videos you have watched?

It’s ok if you don’t, the NSA knows — and from the sounds of it they are willing to share that information.

[1]: http://www.mcclatchydc.com/2013/11/14/208438/americans-personal-data-shared.html

[Verne Kopytoff on new indoor tracking technology for marketers and retailers](http://www.technologyreview.com/news/520811/stores-sniff-out-smartphones-to-follow-shoppers/):

> Forest City Enterprises uses Wi-Fi to monitor foot traffic in most of the nearly 20 shopping centers it owns or manages. It says the data helped it decide where to move an escalator that was interfering with an entrance. The company also measures how long visitors stay after a fashion show or concert. Stephanie Shriver-Engdahl, Forest City’s president of digital strategy, says the company wants to know, “Do they get one soda, hop in the car, and leave? Or are they staying longer?” In the future, foot-traffic data could be used to set lease prices, she says.

Man I hate this stuff. I’m tempted to keep WiFi off on my iPhone until I need it, as LTE is fast enough 80% of the time.

On the other hand, from the retailer perspective, this is going to be a big deal as they struggle to compete with Amazon and the suggestions it makes to customers.

The iPad mini (retina) A7 appears to run slower than the iPad Air’s A7 does, this likely is a heat saving and power saving maneuver, [as Matthew Panzarino notes][1]:

> The reduction may be due to thermal profiles which prevent the device from getting uncomfortably warm to the touch, a complaint with some previous models of iPad. Many iPad Air owners and reviewers have noted that the tablet does not have the same warming issues even with heavy use.

Interestingly I hadn’t noticed that my iPad Air gets hot at all. With the iPad 3 there were many times it would be very warm, hot even. The iPad mini got warm, but never hot. The iPad Air, as best as my memory tells me, has yet to even feel noticeably warm. Even after gaming, Geekbenching — no warmth.

That may be the most impressive upgrade to the iPad line thus far.

#### Side Note

Panzarino [links to this Geekbench result][2] that is assumed to be the new retina iPad mini, clocking it at 1390/2512 on Geekbench 3. That seems to be on par with the iPhone 5s and just slightly lower than the iPad Air. We will need a lot more data points before anything definitive can be shown here though.

What’s more interesting to me is the speed jump from the original iPad mini which clocked in at: 261/495. That’s almost comical to think about in comparison to what the iPads are putting out today. Amazing, really.

I cannot wait for new applications to come out that take advantage of all the CPU power in the newest round of iPads.

[1]: http://techcrunch.com/2013/11/12/retina-ipad-minis-a7-runs-at-1-3ghz-same-as-iphone-5s-and-slightly-below-ipad-airs-1-4ghz/
[2]: http://browser.primatelabs.com/geekbench3/201561

[Charles Arthur][1]:

> That means that Google has gone from having at least 31m users on the iPhone in April 2012 – and perhaps as many as 35m in September 2012, based on a model using a sliding scale of maps ownership – to around 6.3m who are using it monthly on iOS 6 and above.

That his concluding paragraph — the rest of the article says this (more or less) several times over. That’s a massive hit to Google. These numbers are survey numbers and not comprehensive, and therefore should not be taken as gospel — still they show a very disturbing trend for Google.

Mapping is important, but it is important to Google and Apple in different ways. Google uses mapping as a direct source of income (sponsored listing, targeted ads, other creepy things), where Apple uses mapping as indirect income: mostly as a feature to their iOS platform, just another selling point for the device.

So whereas Apple could survive if they killed their mapping client all together (because users could install alternatives), ((Yes, still a lot of people would complain, but even *you* would buy a new iPhone if it didn’t have a native maps app.)) Google would take a substantial revenue hit if they lost all mapping. It’s in that light that I highly doubt the explanation for why Apple switched from Google maps is any more convoluted than: we don’t want to make money for our competitor.

[1]: http://www.theguardian.com/technology/2013/nov/11/apple-maps-google-iPhone-users

Have you ever clicked a phone number in Safari to get the phone app to call that store you were searching for? Maybe you’ve clicked a link to a YouTube video and it opened in the awful YouTube application instead of Safari. In iOS, this interaction between apps happens via URL schemes, which are available to Apple applications as well as third party applications. Everyone uses them without noticing they exist, just like file-type associations on PCs.

### URL Schemes
Out of the box, iOS provides URL schemes for things like HTTP, email, text messaging, maps and telephone numbers. These URL schemes allow iOS to convert strings of text into actions, allowing time saving features like clicking a phone number in Safari to initiate a phone call.

Third party applications use these schemes to enable workflows across apps. Each application can register its own custom handle and scheme. The scheme is how applications interpret the input. The handle is the prefix to URLs that will launch the app, registered with the system.

A sample handle for a Great Application(TM):

GreatApplication://

[X-Callback-URL](http://x-callback-url.com/), a draft specification created by Greg Pierce of Agile Tortoise, has been created to allow two-way communications by applications. It allows sending an action to an application that will return a result back to the original application.

When the URL is opened, iOS launches TargetApp and passes the URL as arguments (see implementation for details of handling incoming URLs). TargetApp will parse the URL, identify the action requested, and translate “Hello” to “Spanish” as passed in the parameters. The “translate” action and its parameters are all specific to TargetApp and should be documented by the developer. If TargetApp is successful in translating the word, it calls the URL in the x-callback parameter to return the result to SourceApp.

### Usage

Applications such as Tweetbot use URL schemes both by providing a scheme to perform actions in Tweetbot and by configuring actions that use other applications, such as sending a photo to Camera+ for editing before tweeting.

Most users have therefore used these URL schemes without knowing they exist, and advanced users take advantage of them to make iOS more powerful and friendly to workflows that would be otherwise unavailable.

Some great examples of advanced workflows can be found in applications such as [Drafts](http://agiletortoise.com/drafts/), [Launch Center Pro](http://contrast.co/launch-center-pro/) and [Editorial](http://omz-software.com/editorial/).

Launch Center Pro gives you a catalog of actions to pick and set shortcuts for. Using Launch Center Pro, you can quickly send a new task to OmniFocus, launch Camera+ in “Take a Picture” mode, append a string of text to a file in Byword and much, much more. Drafts works in a similar fashion, allowing you to create actions based on your text input.

### Issue

URL Schemes are great. They are, however, a source of user input that should never be trusted as safe. To allow convenience without creating a security or privacy risk to the user, any application registering a custom scheme must keep in mind that input could be sent by an attacker.

Safari for iOS, being a web browser, can be used to send actions to applications that implement URL schemes. The easiest way to test this is to find an application on your device supporting URL schemes, building an action in Launch Center Pro, and copying that URL in Safari. Here are a few samples you can try. You must have either WhatsApp or Felix installed for these examples to work.

Launching WhatsApp will prompt you to pick a contact and show you a message ready to be sent with the word “Test”.

**Warning: Clicking this on iOS will launch WhatsApp and prompt you for a contact to send “Test” to**

[Try it.](whatsapp://send?text=Test)

whatsapp://send?text=Test

Launch Felix, which will show a precomposed message ready to be sent.
**Warning: Clicking this on iOS will launch Felix with a message sheet with the text “Testing a few URL scheme things out…”**

[Try it.](felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out…)

felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out...

Not only will Safari prompt you before launching the app, these two actions are built in a way where time is saved, but no action is actually performed automatically. You still have to send the message yourself.

As applications implement actions, it’s easy for a developer to only think about the ease of use of an action and to be tempted to automate it as much as possible, especially if the goal is to use X-Callback-URL to send the user back to his original application.

Compounding the issue is the fact that *Safari will launch these URLs automatically* if they are placed in an inline frame. This frame would perform the same action as the Felix example above, automatically.

<iframe src="felix://compose/post?text=Testing%20a%20few%20URL%20scheme%20things%20out..." height="240" width="320"></iframe>

In the case of well-built actions that require a user confirmation or that do not present a risk, this has little impact. But combined with a dangerous action, it makes automating an attack all that much easier.

I sat down at the end of August and looked at the applications I had on my phone and found two examples of dangerous actions within a few minutes.

### Example 1 – Data destruction in Byword

Byword allows a file to be overwritten through its URL scheme. The action is called “Replace File” and does exactly as it says: It replaces the file named ‘FilenameX’ with the new text you feed it. This string would overwrite ‘Important.txt’ with the string “haha”. For most users, recovering the data is impossible.

byword://replace?location=icloud&path=&name=Important.txt&text=haha

The only thing that mitigated the risk of this vulnerability being exploited is the fact that a file path and name is needed. However, with iCloud being flat, it is not so far fetched to imagine a person would have a file called ‘important.txt’ or ‘todo.txt’. In a targeted attack, someone could try to make an educated guess for a filename. If you sent me a file called ‘bigproject.txt’ and I know you are a Byword user it would be logical to assume you store that file in iCloud. Dictionary attacks could possibly be performed, though a good distribution method for the malicious pages would need to be obtained, as Safari will only launch the first URL targeting an application. By using social media, instant messaging or email, an attacker would distribute the URL to a page with an embedded inline frame designed to overwrite the file. The same method could target a whole population of users by performing a *watering hole* attack. Watering hole attacks consist of targeting a site known to be a frequent destination of your targets. If you were attacking Apple fans, any of the big Apple blogs vulnerable to a cross-site scripting attack would be an enticing target.

[Metaclassy](http://metaclassy.com) responded quickly when I reported this issue and implemented a very good fix by prompting the user before overwriting a file.

[More details on this vulnerability.](http://blog.binaryfactory.ca/2013/09/cve-2013-5725-byword-for-ios-data-destruction-vulnerability/)

### Example 2 – Leak a user’s identity in Tweetbot

Tweetbot is my favorite Twitter client on iPhone, iPad and OS X. It supports multiple actions through its custom URL scheme, including following a user or marking a tweet as a favorite.

This can be useful to add a link for users to follow you easily, but no prompt was presented to the user. This effectively means that you could get a Tweetbot user to follow you without them realizing. While this might seem minor, it is actually an important privacy risk. Imagine you are browsing a website, and an attacker either gives you a link to a malicious page or inserts the malicious inline frame in one of the pages. You barely have time to notice it and Tweetbot opens and follows someone. Once this has happened the person can now link you, or at least your Twitter account, to someone browsing that site or having received that email with a malicious link. As a lot of people, myself included, post enough details on social media to reveal our real identities, this could be used by attackers to reveal the true identity of anonymous users of a website, forum or email address. A political activist using an email account created only for this purpose could be revealed the moment he clicked on the malicious link.

The same can be done by having you favorite a tweet. Remember that Twitter can send notifications for such events, so even if you quickly unfollowed or un-favorited, the damage has been done.

In this image, you can see me receiving a phishing email. When I click the link, it opens Safari, which launches Tweetbot and has me following Justin Bieber.

How embarassing is that?


Tapbots has fixed this issue in Tweetbot V3 for iPhone, and fixes for the iPad and Mac version are coming. For the Mac, there’s a workaround which is to simply disassociate your browser from Tweetbot, as it is not using system-level handles like on iOS. If you’re on iPad, you can still try it out.

**Warning: Clicking this on iOS or OS X could cause you to follow me**
[Try it](tweetbot:///follow/gepeto42)

[More details on this vulnerability.](http://blog.binaryfactory.ca/2013/11/cve-2013-5726-tweetbot-for-ios-and-mac-user-disclosureprivacy-issue/)

### Conclusion

URL schemes will become more popular as developers try to get applications to communicate and enable great workflows. Some were expecting new official methods of app communication in iOS 7, which this has not materialized. Because of that, URL schemes are currently the only practical way for inter-app communications on iOS. As these schemes become more popular, it is important for developers to remember that input from URL schemes could be malicious. Developers should ensure that any action with the potential to damage data, threaten privacy or reveal confidential information should be confirmed by the user before being performed.

If you want to play with URL schemes, I highly recommend using Contrast’s [support site](http://actions.contrast.co/) for Launch Center. Look at the applications you have and how they behave when you send them a potentially dangerous request for action. If you find something, notify the developer before disclosing the issue publicly.

As more users attempt to centralize their computing lives, by replacing their laptops with iOS devices, it is only natural to want better interoperability between apps without interruption. Developers will have to add more support for URL schemes until better methods of inter-app communication are supported by Apple.

I have a gut feeling that there must be some calendar applications that can set up unwanted alarms at 3am, without the user noticing. There must be text editors that silently overwrite data. Surely there are messaging apps that send messages without the user’s consent.

Now we just have to find them.

***

*This was a guest post from Guillaume Ross, an Information Security Consultant, whose writing can be found at [Binaryfactory.ca](http://blog.binaryfactory.ca). If you think you have an article to contribute, [get in touch](https://brooksreview.net/contribute/).*