Tag archives for Security

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.

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):


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.


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.


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.


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.


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.


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.


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.

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.

Securosis Blog | $50K buys how much FDE?

Securosis Blog | $50K buys how much FDE?.

You have no excuse if you don’t encrypt corporate hard drives. Note that I didn’t say laptop hard drives, and that wasn’t a mistake either.

The cost of having two different setups (encrypted laptops and unencrypted desktops) to support plus the risk of having a desktop stolen, which is lower than a laptop but exists, typically make it simpler and better to just encrypt every end user computer.

There are many great solutions that can be integrated or not to existing platforms such as Active Directory, and many provide a good end user experience.

The performance hit is very minimal, centralized management is available, as well as recovery options and features to push the key temporarily to do patch management.

What’s your excuse, next company that will experience a leak due to a stolen computer?

Swedish Greys - a WordPress theme from Nordic Themepark.