Tag archives for Vulnerability

RTFM 0day in iOS apps – Algorithm.dk

RTFM 0day in iOS apps: G+, Gmail, FB Messenger, etc. – Algorithm.dk.

I’ve been talking and writing about this for about a year, and this is another GREAT set of examples and techniques.
If you want to see examples as well as help on how to find these, I highly recommend that you watch my presentation, which I have just posted as well.

Scheming for Privacy and Security

This article was originally posted on The Brooks Review

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, 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, Launch Center Pro and 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

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…

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 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.

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?

Tweetbot URL Vulnerability on iOS

Tweetbot URL Vulnerability on iOS

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

More details on this vulnerability.

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 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.

[CVE-2013-5726] – Tweetbot for iOS and Mac user disclosure/privacy issue

  • Affected Vendor: http://tapbots.com/
  • Affected Software: Tweetbot for Mac, iPad and iPhone
  • Affected Version: Mac: 1.3.3 – iPad: 2.8.5 – iPhone: 2.8.5
  • Issue Type: Lack of user confirmation leading to Twitter action revealing the user’s Twitter identity
  • Release Date: November 1, 2013
  • Discovered by: Guillaume Ross
  • CVE Identifier: CVE–2013–5726
  • Issue Status: Vendor has published version 3 for iPhone which resolves the issue. Vendor has confirmed the fix is in the Mac and iOS V2 codebase and should be released soon.

Summary

Tweebot is a Twitter client for Mac and iOS. Separate iOS versions exist for iPhone and iPad.

Tweetbot has a URL Scheme/association on all versions that allows actions to be triggered from within other applications. The supported actions can be viewed at http://tapbots.com/blog/development/tweetbot-url-scheme

Description

The actions related to following and favoriting do not prompt the user before performing the action. Additionally, Safari in iOS warns the user that an application will be launched only when the URL is used directly, but not when the URL is used within an inline frame. This makes the attack function without requiring user interaction.

 

Tweetbot URL Vulnerability on iOS

Impact

A user browsing the web could click a malicious link or load a page containing a malicious link within an inline frame. The user would then favorite a tweet or follow a user account on Twitter. The attacker can use this action to identify the user browsing the page, to gather followers or to have the victim follow people they would be embarrassed to be associated with.

Proof of Concept

tweetbot:///follow/justinbieber

This URL would have the user follow Justin Bieber. By embedding it in an inline frame, the attack is automated on iOS and on Mac.

<iframe src="tweetbot:///follow/justinbieber"></iframe>

Response Timeline

  • August 27 2013 – Vendor notified
  • August 27 2013 – Vendor acknowledges vulnerability
  • October 24 2013 – Tweetbot v3 for iPhone is released and resolves the issue
  • October 31 2013 – Vendor confirms the fix is in the V2 and Mac code base and will be released soon
  • November 1 2013 – Vulnerability Disclosed

Temporary workaround for the Mac version

Ensure that your browser does not automatically launch Tweetbot.

 

Here is a sample in Firefox.

Tweetbot Prompt in Firefox

 

[CVE-2013-5725] – Byword for iOS Data Destruction Vulnerability

[CVE–2013–5725] – Byword for iOS Data Destruction Vulnerability

  • Affected Vendor: http://metaclassy.com/
  • Affected Software: Byword for iOS
  • Affected Version: 2.x prior to 2.1
  • Issue Type: Lack of validation/user confirmation leading to destruction of data
  • Release Date: 29 Sept 2013
  • Discovered by: Guillaume Ross
  • CVE Identifier: CVE–2013–5725
  • Issue Status: Vendor has published version 2.1 which adds a confirmation prompt to prevent the issue.

Summary

Byword is a text editor for iOS and OS X that can use iCloud or Dropbox to sync documents.

Byword supports actions through X-URLs on iOS.
One of the supported action replaces a file with the value passed through the URL.

Description

The Replace file action in the affected version does not warn the user and replaces the content of the target file with text specified in the X-URL.

The attacker must know the path to the file, but considering iCloud does not have subfolders, it makes it easier to guess filenames such as “todo.txt” file or an “important.txt” file, or the attacker could have received a file created by the victim using Byword and can guess the filename from the title.

Impact

The file can be overwritten and the data could be lost permanently.

Proof of Concept

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

This URL would replace the content of the file “Important.txt” in the user’s iCloud container for Byword with “haha”. By using iframes, the attacker can embed this attack in a web page. Safari on iOS will automatically launch Byword and overwrite the file.

<iframe src="byword://replace?location=icloud&path=&name=Important.txt&text=haha"></iframe>

Response Timeline

  • August 26 2013 – Vendor notified
  • August 26 2013 – Vendor acknowledges vulnerability
  • September 18 2013 – Update released that adds a warning/confirmation screen
  • September 29 2013 – Advisory released

Corrected in 2.1 with this prompt

Confirm Replace

Confirm Replace

Swedish Greys - a WordPress theme from Nordic Themepark.